►
From YouTube: Benefits of a Service Mesh When Integrating Kubernetes with Legacy Services - Stephan Fudeus
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
Benefits of a Service Mesh When Integrating Kubernetes with Legacy Services - Stephan Fudeus & David Meder-Marouelli, 1&1 Mail & Media Development & Technology GmbH
Having Kubernetes for your service landscape is great. Having a service mesh technology inside is even better - but there are legacy services, too. Leveraging the benefits of a service mesh is possible even without migrating all your legacy services into your kubernetes cluster - you can integrate them into the mesh. We'll give a brief overview of the properties and benefits of service meshes in general and specifically how they are configurable in Istio. Then we'll have a look at the expansion of the mesh to services outside of kubernetes. We'll go into how the expansion is done, what needs to be done in the legacy systems and what obstacles we had to overcome. On a sidetrack we'll show a "service mesh light", a mechanism to make legacy services protected by IP ACLs accessible from your kubernetes cluster, without deploying a full fledged service mesh implementation.
https://sched.co/MPep
A
Check
cool
all
right,
how's,
everyone
doing
cool,
so
my
name
is
subbu
I'm,
going
to
be
the
track
host
for
this
afternoon,
I'd
like
to
introduce
this
session
by
Stephan
and
David.
They
are
from
one
and
one
male
and
media.
They
are
going
to
talk
about
how
to
integrate
kubernetes
with
legacy
systems
using
service
mesh
and
without
further
ado.
Here's
Stephan
and
David.
B
C
Hi
everybody.
Do
you
me?
Okay,
hi
everybody
wow,
that's
quite
a
crowd,
as
far
as
who,
as
we
could
see,
from
sket
about
600
something
people
would
like
to
come,
or
of
course
some
of
them
just
have
two
or
three
in
parallel,
but
it's
quite
a
crowd
and
still
people
are
coming
in,
but
we
have
a
tight
schedule.
So,
let's
get
started.
We
have
some
seats
left
here
and
the
middle
seat
in
the
first
row
is
still
free,
so
everybody
who
would
like
to
volunteer
okay.
C
So
this
talk
is
about
service,
mesh,
loves
legacy,
likes
legacy,
service,
mesh
and
legacy
versus
legacy,
maybe
hates
legacy.
We
will
see
in
the
talk
what
we
did
at
one
in
one
is:
we
have
a
bunch
of,
we
have
a
freshly
new
kubernetes
cluster
and,
of
course
we
have
a
bunch
of
legacy
services
and
what
we'll
see
in
this
talk
is
how
we
tried
to
merge
both
worlds
by
using
service
mesh
technology
and
how
good
we
did
or
how
bad
we
did
so
who
are
we?
C
My
name
is
Stefan
videos,
I'm
an
expert
for
container
platforms.
I
have
a
16
years
track
record
of
distributed
systems,
I
work
in
one
on
one
meteor,
since
2017
and
I'm,
with
with
the
one
in
one
group
since
2005.
My
current
main
job
is
being
a
product
owner
for
our
internal
kubernetes
cluster.
So
a
set
of
clusters
we
just
used
for
internal
purposes
where
our
application
operation
teams
are
running
their
application
zone.
Okay,.
B
I'm
damaged
miramar
ad
I
am
a
systems
architect
with
one
alone
made
in
media.
Originally
I
started
as
a
physicist
and
gradually
moved
through
HPC
to
the
internet
business
and
that
shift
acquired
like
15
years
ago
and
for
a
couple
of
years,
I'm
a
systems
architect
with
the
focus
on
everything
connected
with
automation,
so
that
that's
a
lot
of
work
and
at
the
interface
between
standardizing
software
development
and
and
creating
the
matching
infrastructure,
together
with
people
like
Stefan.
B
B
Actually,
we
have
something
like
over
9,000
employees
at
a
time
close
to
100,000
servers
and
10
data
centers
distributed
worldwide.
So
there's
quite
a
number
of
challenges
to
main
business
units.
Applications
is
essentially
what
you'd
call
that
hosting
and
the
mail,
mail,
email
and
online
data
storage,
business
and
X
has
would
be
mobile
phones
and
landlines.
So
our
business
unit
is
the
one-on-one
mailed
media.
As
you
can
see
here,
we
are
offering
mainly
email
services
with
about
close
to
36
million
active
users,
currently
most
of
them
using
free
accounts,
but
there's
premium
services
as
well.
B
You
see
the
logos
of
a
couple
of
brands
you
may
or
may
not
have
seen
them
gmx
and
web
TV
being
the
largest
ones
in
Germany
and
mail.com
are
also
being
available
internationally,
as
I
mentioned,
that's
the
product,
the
product
portfolio
that
made
a
media
is
offering
main
thing.
Obviously,
everything
around
email,
email
contacts,
calendar
stuff
like
that.
We
also
have
an
online
office
offering
so
that's
sort
of
similar
to
what
you
know
from
Google
probably-
and
we
also
offer
cloud
storage
things
think
of
Dropbox
or
Google
Drive.
B
So
how
do
we
get
these
products
to
our
customers?
And
so
this
is
the
architecture
you
as
simple
as
it
can
be,
so
our
product
guys
have
product
ideas.
Obviously,
developers
turned
that
into
code,
which
is
thought
somewhere
in
get
lab
together
with
the
configuration
for
the
applications
from
there.
We
have
a
build
system,
let's
think
Jenkins
or
gate
lab
CI,
which
produces
the
deployable
artifacts,
which
are
stored.
B
In
a
repository
like
artifactory
from
j
frog,
and
we
also
store
the
configurations
together
with
the
artifacts
there,
we
pick
the
the
artifacts
up
with
with
a
tool
for
deploying.
We
are
using
go
CD
for
orchestrating
things
like
that.
Under
the
hood,
we
are
doing
very
lot
of
graphic,
rotate,
sorry
great
amount
of
things
using
ansible,
which
is
a
good
thing
because
we're
tangible
we
can
deploy
to
the
host
based
world
about
15,000
hosts,
which
we
currently
have
an
Malin
media.
B
C
So
that's
about
the
context
in
which
we
are
living
and
working
and
when
we
started
kubernetes,
we
hadn't
we
of
course
had
a
strategy.
Why
we
want
to
do
containers
and
you
see
parts
of
them
there.
We
provide
kubernetes
as
a
central
installation
for
the
application
operations
teams
and
we
use
that
for
centrally
providing
orchestration
of
containers
within
the
101
mainland
media.
The
main
goal
we
want
to
achieve
is
having
fast
deployment
cycles.
C
We
want
to
enable
the
application,
development
and
application
operator
operating
teams
to
fastly
deploy
their
new
changes,
their
customer
demands
to
a
running
infrastructure
and
as
well,
developing
a
new
product,
and
previously
before
we
had
kubernetes
as
a
platform.
Of
course,
we
partially
used
virtualization.
We
use
bare
metal
as
well,
depending
on
the
requirements
and
every
time
a
team
had
a
new
product
idea.
First,
new
systems
had
to
be
set
up,
a
new
public
code
had
to
be
written
and
with
kubernetes,
that's
just
easy.
You,
you
have
you're
already
running
infrastructure.
C
The
capacity
is
already
there.
You
just
throw
your
deployments
into
the
cluster
and
everything
works
just
out
of
the
box
and
we
have
a
focus
for
multi-tenancy.
So
this
is
why
at
least
we
try
taking
part
in
the
multi-tenancy
working
group
of
kubernetes
as
well,
because
multi-tenancy
is
crucial
for
us,
because
we
cannot
provide
a
kubernetes
cluster
for
every
application
operations,
teams
or
even
every
development
team
for
their
own
stuff.
C
We
provide
central
clusters,
it's
about
15
clusters
so
far
with
overall,
like
500
servers
and
in
these
clusters,
we
provide
each
tenant
each
application
operations
teams
their
space
and
we
separate
them
from
each
other,
of
course,
by
using
our
back
and
port
security
policies,
our
benefit
is,
we
have
friendly
users,
so
we
don't
need
to
have
strong
multi-tenancy
requirements.
It
is
sufficient
to
just
have
them
there,
space
where
they
cannot
break
the
others.
Of
course,
as
nearly
everybody
who
is
going
for
kubernetes,
we
focus
on
micro
services.
C
We
do
not
try
to
do
a
lift
and
shift
of
the
existing
monolith,
but
we
try
to
make
small
services
and
then
put
them
into
kubernetes
as
set.
We
have
multiple
clusters
and
we
split
them
on
multiple
dimensions.
We
have
a
split
between
front-end
and
back-end
networks
and
only
the
front-end
networks,
of
course,
are
exposed
to
the
public
Internet.
We
have
multiple
data
centers,
where
our
clusters
are
running
in,
in
fact,
that's
three
clusters,
one
in
the
US
and
two
in
Europe.
C
We
have
a
split
according
to
life
and
non-life
systems
and
interesting
is
we
do
not
use
virtualization
for
running
kubernetes
clusters,
because
since
we
have
a
central
infrastructure
provisioning,
we
said
hey
that
we
don't
need
that
additional
layer.
We
can
really
just
use
the
full
power
of
another
thing
which
gets
important
when
we
talk
about
service
mesh
later
is
our
network
infrastructure
in
our
clusters
for
the
pot
ciders
and
the
service
ciders
we
use
non-routable
IP
addresses,
so
they
are
not
routable
outside
of
the
kubernetes
clusters
and
they
are
reused.
C
B
On
top
of
that
thousand
applications,
as
you
can
probably
imagine,
not
all
of
them
are
micro
services.
Yet
so
it's
getting
worse
with
micro
service
transformation,
that's
generating
a
pretty
messy
mesh
of
dependencies,
which
needs
to
be
handled
some
way
or
the
other.
On
top
of
that,
it's
obviously
we
probably
will
not
be
able
to
move
all
of
them
into
kubernetes
and
and
containers,
because
some
many
are
not
yet
cloud
native
or
cloud
ready.
B
B
So
dawa
is
the
main,
the
main
programming
language
and
one
on
one
Springwood,
the
current
standard
good
old
spring
before,
but
we
also
have
PHP.
We
have
a
little
bit
of
JavaScript
and
nodejs
stuff
like
that
and
a
bunch
of
other
things,
but
on
some
of
all
applications,
you'd
like
to
have
a
number
of
services
for
observability
for
telemetry
for
a
lot
of
things.
So,
besides
your
actual
application
code,
an
entire
stack
of
libraries
usually
are
used
in
these
applications.
B
So
this
has
to
this
is
some
implementation
effort
and
there's
this
substantial
duplication
of
work.
And
so
wouldn't
it
be
nice
to
have
something
that
looks
like
that,
which
removes
all
these
layers,
which
you
need
in
all
the
applications
from
the
applications
themselves
and
puts
them
into
infrastructure.
Components
like
using
a
proxy
which
is
handling
that
totally
language
agnostic,
totally
platform
agnostic
and
so
reduces
that
duplication
and
lets
the
developers
focus
on
the
functionality
of
their
application.
C
So
that's
where
the
benefits
of
the
service
mesh
come
into
play.
The
main
goal
of
the
service
mesh
is
to
deal
with
the
service
mess
of
micro
services,
because,
as
you,
if
you,
if
you
gather
additional
Microsoft,
it
gets
a
hundred
to
get
two
thousand
and
gets
thousands
and
you
need
to
keep
track
what
you
have
there
and
how
they
behave.
You
need
to
have
observability.
We
heard
that
term
quite
a
bit
the
last
two
days.
C
What
service
measures
are
doing?
Is
they
externalize
required
standard
functionality
like
extracting
telemetry
out
of
the
services,
routing
of
requests,
doing
a
be
switching
blue/green
deployments,
Cannery
deployments?
They
help
us
with
doing
circuit
breaking.
So
if
you're
upstream
service
has
a
problem
and
is
down,
then
it
just
cuts
the
circuit
especially
important.
If
you're
upstream
service
just
gets
slow,
you
don't
want
to
have
a
slow
application
yourself,
so
you
cut
the
application
off
and
then
you
can
work
just
with
having
no
data.
C
Of
course,
circuit
breaking
does
only
work
properly
if
your
application
is
aware
of
that
that
the
that
it's
optional-
and
it's
just
not
there
at
the
moment
and
can
behave
accordingly
by
using
cache
data,
for
example,
rate
limiting,
is
always
an
interesting
thing
when
you
especially
know
that
your
service
can
cope
with
a
specific
amount
of
load
and
you
wanna.
You
want
to
take
care
of
the
point
in
time
where
you
get
too
many
requests,
but
you
still
want
to
serve
those.
You
know
your
support.
C
If
you
don't
do
rate
limiting,
it
might
be
that
your
service
breaks
down
completely,
and
then
you
have
nothing
anymore
and
the
most
important
thing
for
a
service
mesh
for
us
was
doing
encryption
on
the
transport
layer
and
having
authentication
and
authorization,
and
especially,
we
will
see
that
in
a
few
slides
that
that's
especially
important
for
us
when
connecting
kubernetes
services
with
house
based
or
legacy
services,
another
benefit
of
the
service
mesh
is
that
they
can
be
configured
in
a
declarative
way.
So
no
change
to
be
applications
themselves.
C
I
can
just
declare
some
yellow
stuff
and
we
will
see
an
example
in
a
second
I
can
just
declare
a
bit
of
llamo
and
then
have
my
application
enriched
by
that
functionality.
I
can
maintain
them
in
a
set
in
the
central
fashion.
I
can
do
infrastructure
as
code
I
have
all
my
configuration
just
in
the
central
git
repository
and
I.
Do
every
change
there,
I
roll
that
out
and
I
have
everything
there
and
one
other
prime
feature
of
a
service
mesh.
Is
that
it's
language
agnostic?
C
We
just
saw
the
slide
where
we
had
an
exemplary
Java
stack
of
applications.
But
of
course,
usually
you
don't
have
have
homogeneous
software
stacks.
You
have
Java
stacks,
you
have
PHP,
you
have
JavaScript,
you
have
Fortran
code,
maybe
we
don't
have
em
luckily,
and
you
would
need
to
do
all
the
service
mesh
functionality
for
each
language
again
and
again
and
with
the
service
mesh
I'm
solving
that
on
V
and
on
the
infrastructure
level.
It's
completely
agnostic
from
the
language.
C
It
just
works,
at
least
for
the
base
functionality,
and
what
we
did
is
trying
that
first
with
is,
do
yesterday.
I
wasn't
the
intro
session
to
link
early
and
there
was
one
one
Twitter
post
on
a
slide,
and
that
said,
if
you
want
to
do
it
will
go
for
service
mesh
use
lingua
G
first,
because
then
you
already
have
a
basis,
and
then
you
can
go
for
is
geo
and
try
that
for
nine
months
we
will
see
in
a
second
if
it
took
nine
months
for
us
or
not.
We
still
started
with
this
do
so.
C
How
would
that
work
in
a
service
mesh?
And
as
you
see
here,
you
have
three
parts
which
have
their
services
a
B
and
C,
and
each
of
them
have
just
a
proxy
attached,
and
usually
you
wouldn't
you
to
have
another
client
within
the
cluster
which
has
its
own
proxy.
It
interacts
by
using
the
proxy
transparently.
You
don't
need
to
do
that
yourself
in
the
application.
C
It
interacts
with
the
service
a
and
port
1,
and
then
your
request
just
gets
forwarded
through
your
different
pots
and
if
you
have
a
destination
in
the
end,
then
that
destination
within
the
cluster
is
still
attached
to
a
proxy.
But
what
if
your
client
application
or
your
destination
application
is
not
part
of
your
kubernetes
cluster,
then
if
you
has
something
like
an
ingress
gateway
and
an
egress
gateway,
so
you
have
a
client
which
is
not
service
measure
or
not.
C
Is
too
aware
outside
of
your
kubernetes
cluster
requests
from
that
client
would
be
ingested
in
an
ingress
gateway
like
an
ingress
controller
in
standard
kubernetes,
and
that
has
its
first
instance
of
a
proxy
and
every
proxy
to
proxy
connection.
Then
has
the
full
flexibility
and
the
full
capabilities
of
the
service
mesh
like,
for
example,
the
TLS
encryption
between
the
proxy
and
the
ingress
gateway
and
the
proxy
of
POD
one
would
already
be
handled
by
sto.
The
egress
gateway
is
an
optional
component.
You
don't
need
to
do
that.
C
You
can
directly
connect
to
the
outside
world
without
the
egress
gateway
as
well,
but
the
egress
gateway
can
provide
additional
functionality.
If
you
have
a
dedicated
host,
which
has
maybe
a
dedicated
IP
address,
and
only
that
one
is
from
a
firewall
perspective-
allowed
to
connect
to
the
outside
world
out
of
the
kubernetes
cluster
I
promised
I
will
show
you
a
bit
of
Yamaha
SEO
would
be
configured
not
the
issue,
control
plane
itself,
but
just
for
a
given
service.
What
you
see
here
is
you
have
a
client
pod
and
a
virtual
service
and
the
destination
rule.
C
These
are
two
CRTs
for
Sto
and
then
the
request
would
go
to
the
destination
pot
and
what
you
need
to
do
for
a
sto
service
is
you
need
to
configure
a
so-called
virtual
service?
The
virtual
service
hasn't
in
this
case
an
HTTP
service.
It
has
a
roud
definition
and
says
75%
of
the
requests
for
the
reduced
service
go
to
version
1
and
25%
of
the
request
just
go
to
version
2.
So
what
is
subset,
v1
and
subset
v2?
This
is
defined
in
the
destination
rule.
There.
You
have
the
subset
declaration
and
say
subset.
C
V1
is
made
up
of
all
the
pots
which
have
just
this
label
combination,
so
the
pots
need
to
have
a
label
version.
V1
and
then
it's
part
of
subset,
we
want
so
that's
already
it
for
each
subset
or
generally,
you
can
provide
a
dedicated
load,
balancer
specification.
So
if
you
want
to
distinguish
between
random
robin
or
round
robin.
B
That's
what
the
master
expansion
of
this
you
can
do
and
what
we
work
mostly
with
us,
the
master
expansion
that
has
been
offered
in
version
1.0
and
the
principle
is
relatively
easy.
You
just
install
the
envoi
proxy
at
a
side
of
your
application
on
the
virtual
machine
or
physical
host
and
just
connect
that
simply
to
the
control
plane
of
Sto,
which
still
resides
on
the
kubernetes
cluster.
B
As
Don
mentioned,
TLS
encryption
mutual
TLS
encryption
was
the
main
focus,
because
some
of
the
applications
are
not
especially
the
internal
ones
are
not
totally
capable
of
running
TLS
by
themselves.
So
that
was
very,
very
important
and
getting
client-side
authentication,
it's
very
important
to
replace
that
ACL
stuff
in
particular,
in
the
server's
mesh.
B
We
can
declaratively
connect
things
and
that
replace
the
ACS,
and
this
instantly
also
gives
you
all
the
telemetry
and
observability
circuit
breaking
stuff
and
all
the
features
that
is
to
just
brings
with
the
proxy,
and
this
is
how
it
essentially
looks
like
I
just
explained.
It's
essentially
installing
the
proxy
on
the
hosts
connected
to
the
control
plane
and
what
it
immediately
worked
was
calling
host
based
services
from
the
kubernetes
cluster.
C
So,
but
mainly
we
are
here
because
of
the
problems
we
had
when
using
SEO,
at
least
in
our
setup.
I
will
not
say
that
it's
not
our
fault,
I'm
sure.
Quite
of
the
things.
What
kind
of
delays
have
been
our
fault?
Maybe
not
using
most
priority
on
that,
but
we
are
here
to
show
what
we
stumbled
upon
first
thing:
we
noticed
our
security
concerns.
I
mentioned
we
run
in
a
multi-tenancy
environment
and
the
multi-tenancy
Pro
environment
has
put
security
policies.
C
So
usually
we
don't
allow
pots
running
as
root,
and
usually
we
don't
allow
pots
writing
in
their
topmost
container
layer
if
they
want
to
write
something
they
should
mount
volumes.
So
the
sto
control
plane
doesn't
do
that
mostly
ok,
the
control
plane
components,
we
can
say:
hey,
that's
managed
objects
from
us
as
a
cluster
provider.
That's
fine,
but
in
is
21.0
and
before,
in
fact,
before
is
to
see
and
I
existed,
the
proxies
for
each
application
come
into
play
by
being
a
sidecar
container
in
your
application.
C
Pods,
and
these
sidecar
containers
are
enriched
either
in
an
automatic
fashion
or
in
a
manual
fashion.
Manual.
Fashion
means
you
have
an
sto
control,
command-line
tool
which
enriches
your
kubernetes
manifest,
and
yet
then
you
can
do
it.
You
control,
apply
and
send
them
to
the
cluster,
the
sidecar
container,
the
proxy
sidecar
or
not.
No,
in
fact,
not
the
really
the
proxy
sidecar,
the
init
container,
which
changes
your
IP
tables
rules.
C
This
needs
privileged
mode
and
it
needs
net
admin
capabilities
and
since
that's
done
as
part
of
an
application
deployment,
these
are
privileges
and
application
operator
needs
to
have
and
not
the
cluster
operator,
and
this
is
something
we
really
did
not
like,
and
it
was
a
problem
for
us.
The
same
problem
worked
with
with
the
book
info
sample
application
of
Sto.
They
want
to
run
as
root
as
well
in
most
places.
C
I
think
this
has
improved
in
1.1,
but
still
not
at
the
end,
but
we
have
some
patches
which
we
would
like
to
submit
to
get
that
fixed
as
well.
The
citecar
injection,
that's
the
automatic
mechanism,
I
mentioned
you
can
just
inject
your
manifest
into
a
tech
namespace
and
then
an
admission
controller
will
enrich
your
configuration.
If
you
use
port
security
policies,
you
get
a
problem
with
the
order
of
events.
C
C
So
we
were
not
able
to
submit
telemetry
data
and
the
inbound
part.
So
you
have
a
host
based
installation
outside
of
the
cluster
and
want
to
call
a
kubernetes
service
with
mesh
expansion
that
we
get
that
we
didn't
get
running
at
all,
because
it
wanted
to
contact
the
pot.
Ip
addresses
of
the
destination
service
as
well
and
MPLS
did
not
work
out
of
the
box
as
well.
B
Okay,
so
in
the
end
it
turned
out
that
sto
1.0
was
not
essentially
suitable
for
our
problem
and
our
use
case
to
run
it
was
too
many
things
we
had
to
tweak
too
many
things
that
didn't
work
smoothly
and,
in
particular,
Stephan
explained.
The
expansion
didn't
work
as
as
good
as
we
needed
that,
so
that
was
actually
a
blocker
of
migrating
from
migrating,
a
lot
of
lots
of
service
services
into
the
kubernetes
cluster,
because
in
that
case
they
wouldn't
be
able
to
reach
their
dependencies.
B
So
we
needed
an
intermediate
solution
for
helping
our
colleagues
to
migrate
your
stuff.
What
we
did
as
an
intermediate
thing
was
something
we
internally
called
the
service
mesh
light,
but
don't
take
photos
of
that
place.
It's
all
online,
so
we
mimicked
a
set
up.
That
looks
a
little
like
a
service
mesh,
but
it
isn't
anna
kubernetes
a
world.
We
put
a
spread,
sidecar
container
in
front
of
that
to
unload
client
certificates
and
TLS
on
the
host
sides.
B
We
put
an
Apache
which
in
most
cases
we
already
have
available
to
unload
to
TLS
encryption
and
verify
the
client
certificates.
We
could
sort
of
semi
automate.
All
of
that
and
that
helped
a
lot
of
colleagues
to
proceed
with
their
kubernetes
migration.
But
of
course
that's
not
the
thing
we
want
to
do
in
the
long
run.
So.
C
S21
one
has
been
released
is
two
one
one
to
the
rescue
spoiler.
It
got
a
lot
better.
The
control
plane
connections-
yes,
we
got
them
running
with,
is
to11
without
a
problem.
Outbound
expansion,
so
I
have
a
kubernetes
service
and
want
to
talk
to
some
host
based
installation
outside
of
kubernetes
works
like
a
charm,
em,
TLS
setup,
yes,
M
TLS
as
well,
or
both
between
kubernetes
servers
and
expansion
servers
and
for
the
control
plane.
Components
yes
works
out
of
the
box,
and
the
one
thing
I
mentioned
with
the
iptables
configuration
is
TOC.
C
Ni
is
out,
runs
with
admin
privileges
in
as
a
CNI
plugin
and
not
with
operator
or
application
operator
permissions
anymore.
So
even
our
security
concerns
there
have
been
solved
with
is
geo
1
node
1,
but
there
always
is
a
but
inbound
expansion
still
not
working
so
far
because
it
tries
to
reach
pod
IP
addresses
directly
the
automatic
cycler
injection
the
thing
with
the
order
and
port
security
policies.
We
did
not
test
that
successfully
with
1.1
as
well
the
documentation
and
general
e-service
mesh.
Or
is
it's
complex?
It's
not
something
you
should
just
take
on
lightly.
C
It's
absolutely
doable
or
I
hope
at
least,
but
it
is
complex
and
the
documentation
is
partially,
but
that's
a
matter
of
development
for
a
fast
running
thing.
The
documentation
is
partially
inconsistent
and
one
thing
which
is
very
important
for
us
multi-tenancy.
That's
a
bit
unclear
still,
who
is
responsible
for
deploying
which
artifacts
into
the
cluster
like
who
is
doing.
C
What's
up
next,
of
course,
solving
the
remaining
issues
to
have
a
final
picture
on.
If
issue
is
the
right
choice
for
us
to
use,
we
want
to
get
the
inbound
message,
expansion
running.
We
need
to
evaluate
that
in
large
scale.
They
have
been
multiple
discussions
regarding
the
performance
overhead
of
service
mesh.
We
want
to
test
that
with
our
test
setup.
We
do
have
services
which
have
thousands
of
requests
per
second,
so
that
most
likely
those
services
will
not
be
one
of
the
first
candidates
to
do
yeah.
C
That's
part
of
the
production
readiness
things
redundancy
needs
to
be
tested
that
it
works
properly.
We
need
to
tune
the
permissions
of
the
control
plane,
components
on
the
end
of
the
series
that
goes
again
into
the
multi-tenancy
thing
and
yeah
performance
and
overhead
I
already
mentioned,
and
we
can
get
more
benefits
out
of
Sto,
especially
it
still
won
that
one
on
further
multi
cluster
connectivity,
that's
definitely
a
topic
for
us.
C
We
want
to
connect,
for
example,
our
front-end
and
back-end
clusters,
or
make
it
available
that
we
connect
one
cluster
of
one
data
center
with
the
with
a
corresponding
cluster
in
the
other
data
center.
So
to
help
with
faint
over
to
have
in
mesh
faint
over
the
locality
based
routing
goes
into
the
direct
Asian
direction
as
well.
We
want
to
have
short
the
shortest
possible
data
paths,
so
why
switch
over
to
the
other
data
center?
If
there
is
a
locally
deployed
service,
maybe
even
really
cool
and
spiffy
interoperability.
C
Currently
we
plan
for
multi
cluster
with
just
having
a
certificate
of
the
same
root
CA,
but
we
want
to
have
general
interoperability
by
using
the
spiffy
standard
and
is
to
has
support
for
that
error.
Scenarios
are
to
be
tested
anyway,
and
authorization
is
as
well
something
we
did
not
look
into
so
far,
so
specific
request
based
authorization.
B
Okay,
so
in
summary,
I
can
probably
say
that
it
looks
like
is
still
one
that
one
fits.
What
what
we
need
most
of
the
things.
Look
fine
in
particular
compared
to
one
or
zero.
A
couple
of
things
need
to
be
clarified,
but
yeah,
it's
it's
doable.
We
think,
as
you
heard,
it's
not
too
easy
to
set
it
up,
and
a
couple
of
organizational
questions
need
to
be
clarified.