►
From YouTube: Keynote: Multicluster Strategies to “Kubernetify” Legacy Apps - Sai Vennam, Developer Advocate, IBM
Description
Join us for Kubernetes Forums 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
Keynote: Multicluster Strategies to “Kubernetify” Legacy Apps - Sai Vennam, Developer Advocate, IBM
Container-based application architectures powered by Kubernetes have seen large-scale adoption and have become the industry standard for developing new cloud-native applications. However, the overwhelming majority have existing legacy applications they need to modernize, while also innovating with the latest and greatest cloud-native technologies.
A standard pattern for modernization is to leverage a hybrid or multi-cluster approach, easing the path to the cloud by integrating your apps running anywhere: on-prem, private and public clouds. In this talk, I’ll outline key modernization strategies using multi-cluster Kubernetes, and service mesh capabilities with Istio. Then we’ll dive into a real-world demo, where we'll “kubernetify” a sample legacy application and integrate it with services across multiple clusters, all while maintaining a stack based on open-source technologies.
A
So
my
name
is
sy
venom
and
I'm.
A
developer
advocate
and
offering
manager
with
IBM
and
I
also
create
a
lot
of
YouTube
videos,
so
around
kubernetes
and
cloud
computing-
and
you
know
containerization
concepts,
so
I'm
really
excited
to
be
here
in
Sydney.
I
want
to
thank
you
all
for
having
me
today
really
quickly.
We're
gonna
be
talking
about
multi
cluster
strategies
and
then
you
all
can
go
ahead
and
grab
a
drink,
so
I'll
go
ahead
and
keep
this
short
now.
A
Multi
cluster
is
a
growing
pattern.
If
you've
seen
success
with
a
single
cluster,
chances
are
you're,
gonna
start
scaling
it
up
to
even
more
now.
I
was
recently
at
cube
con
San
Diego,
where
there
was
very
interesting
talk
about
a
company
who
was
scaling
up
with
a
single
kubernetes
cluster
to
over
seven
eight
thousand
nodes.
At
that
point,
things
start
to
degrade.
In
their
case
it
was
at
C
D.
So
you
could
try
to
stick
with
one
cluster
and
keep
scaling
it
infinitely,
but
chances
are
you're.
A
A
I'll
add
on
to
that
with
another
number
81
percent,
that's
the
number
of
companies
that
are
using
multiple
public
clouds
and
one
or
more
private
or
dedicated
clouds.
Now
this
is
according
to
the
2019
IDC
Multi
cloud
management
survey.
Now
the
key
takeaway
from
this
is
that
companies
are
trying
to
avoid
vendor
lock-in
they're,
clearly
going
towards
a
pattern
where
they
take
advantage
of
multiple
cloud
environments,
but
this
all
goes
to
say
that
companies
are
doing
multi
cloud,
not
particularly
multi
cluster,
but
I
think
this
is
where
kubernetes
comes
in.
A
Companies
are
avoiding
vendor
lock-in
and
kubernetes
being
an
open
source
community
driven
solution
that
gives
you
consistency
across
multiple
clusters:
it's
a
sweet
spot
for
kubernetes
and
multi
cluster
and
multi
cloud
to
start
thinking
about
why
you
would
want
to
have
multiple
clusters,
we'll
start
with
a
simple
example:
DevOps,
let's
say
your
development
team
has
a
single
cluster.
Your
testing
team
should
also
get
their
own
cluster
to
test
with,
and
finally,
you
want
a
production
cluster
to
run
and
and
can
I
get
have
those
assets
accessible
for
your
end-users.
A
Now,
that's
a
simple
one:
that's
three
clusters
off
the
bat.
Next,
let's
start
thinking
about
multi
region
or
H,
a
so
say
we
want
to
deploy
Prada
environments
in
both
Seoul
and
Sydney.
Maybe
we
have
end-users
in
those
areas,
so
we
want
to
be
more
localized
of
the
global
load
balancer
that
leads
them
there
and
in
addition,
let's
say
just
in
case
one
of
those
clusters
or
apps
goes
down.
You
can
failover
to
a
cluster
in
a
different
region.
That's
another
reason
and
you
can
start
to
see
the
number
of
clusters
can
go
up
now.
A
The
last
reason
is
one
that
we've
already
talked
about
and
and
that's
multi
cloud.
Let's
say
you
have
all
of
this
running
in
a
single
cloud.
Well,
chances
are
your
customer,
you
guys
are
thinking
about
using
multiple
clouds.
81%
like
we
saw
so
when
you
start
scaling
these
out
to
different
clouds,
where
you
can
take
advantage
of
their
own
advantages.
Each
cloud
has
their
own
set
of
advantages
and
and
tooling
that's
built
and
kind
of
customized
with
their
solution.
You
start
to
see
the
problem.
A
You
have
multiple
clusters
across
multiple
regions,
let's
break
it
down
a
little
bit.
Further
kubernetes
has
solved
this
problem
on
a
smaller
scale,
right
so
with
worker
nodes,
if
you're
an
Operations
team
or
you're
an
operator
on
an
Operations
team
and
you're,
trying
to
deploy
an
asset
across
those
worker
nodes
gone
are
the
days
where
you
have
to
worry
about.
Where
and
scheduling
out
where
you
want
to
run
those
asset,
scaling
them
up
and
down.
You
just
tell
kubernetes,
you
want
it
and
it
takes
care
of
the
rest
for
you.
A
But
what
happens
when
you
start
having
more
clusters?
It
starts
it's
starting
to
look
very
familiar
with
what
kubernetes
does
with
worker
nodes.
These
are
kind
of
starting
to
look
like
a
layer
that
needs
another
abstraction
on
top.
So
when
you
start
thinking
about
multiple
clusters,
you
start
thinking,
hey
I
need
another
abstraction
layer.
Now,
one
of
the
first
things
you'll
probably
want
is
a
visibility
layer.
So,
basically,
the
ability
to
see
what's
running
and
where
it's
running
so
your
pods
deployments
and
that
kind
of
thing.
A
In
addition,
you
might
be
thinking
about
what
version
are
all
my
clusters?
Are
there
any
of
them
that
are
down
next,
you
start
to
think:
hey.
I
want
to
be
able
to
automate
the
deployment
to
federate
out
kubernetes
resources,
things
like
pods
services
deployments,
maybe
even
network
policies.
Then
you
start
to
realize:
I
need
a
Federation,
API
server
now
in
a
perfect
world
that
visibility
layer
would
pull
that
data
from
the
API
server
as
well.
A
Now
the
last
layer
that
you
need
here,
it's
kind
of
a
different
problem
that
we
talked
about
with
the
Federation
API
server,
its
micro
service
management.
So
this
is
something
where
a
service
mesh
can
really
excel
and
help
you
solve
this
across
clusters.
So,
as
an
example,
let's
say
a
service
running
in
Seoul
goes
down
and
all
of
the
other
services
that
are
dependent
on
it
can
now
failover
to
a
different
service
in
a
different
region.
Now
these
are
flows
that
you
can
manage
with
something
like
a
service
mesh.
A
So
my
goal
today
is
to
talk
about
kind
of
some
of
the
capabilities
that
are
out
there
because
all
of
these
capabilities,
all
these
challenges
that
I
laid
out
here,
they
all
need
a
control
plane.
Now
some
of
the
solutions
out
there
today
are
helping
tackle
exactly
what
you
need,
but,
as
we've
seen,
the
problem
is
in
kind
of
a
different
part
of
the
overall
technology
stack.
So
we'll
start
with
introducing
cube
bed.
A
Cupid
is
actually
sponsored
by
a
kubernetes
special
interest
group,
so
it's
called
cig
multi
cluster
now
they're,
currently
in
alpha
and
they've
gone
through
a
couple
of
iterations.
If
you'll
remember,
they
started
off
with
something
called
uber
Nettie's
and
that
then
became
cube,
fed
version,
one
which
is
now
deprecated.
A
Now
there
aren't
two
version
two
now,
if
you
want
a
community
driven
solution
to
do
multi,
cluster
and
multi
cluster
capabilities,
this
is
the
best
way
to
get
it
and
right
now
they
have
a
survey
out
where
they're
trying
to
identify
from
consumers
like
you
what
they
need
to
develop.
What
are
the
capabilities
that
consumers
really
need
so
get
on
their
slack
channel
Google,
cig
multi
cluster?
If
you
want
a
community
driven
solution
for
multi
cluster,
this
is
a
great
place
to
get
started.
A
Next,
we've
got
Razi
so
over
the
years
IBM,
as
has
been
running
over
you
know
now,
20
and
clusters
in
production
and
we've
picked
up
on
some
key
tips
and
and
solutions
that
capabilities
that
we
built
in-house
to
solve
how
to
manage
that
many
clusters,
we
realized-
hey,
let's
contribute
this
to
the
community,
so
Razzie
is
something
that
we
announced
recently
actually
at
cube,
con
Barcelona
and
it's
a
multi
cluster
continuous
delivery
tool
for
kubernetes.
So
when
we
run
that
many
clusters
in
production,
we
need
to
be
able
to
know
what
versions
they
are
all.
A
We
need
to
be
able
to
know
if
they're
running,
if
they're,
healthy
and
and
all
of
those
kind
of
things
we
need
to
get
that
visibility,
but
then
also
do
things
like
pushing
out
new
secrets
or
certificates
or
network
policies,
and
you
can
get
started
with
that
today,
at
Razzie
IL,
the
last
one
I
want
to
mention
here
is
Sto.
Sto
is
actually
a
open
source
project,
as
you
guys
might
know,
it's
a
service
mesh
that
allows
you
to
connect,
secure
control
and
observe
services.
A
A
If
we
put
some
of
these
solutions
together,
so
IBM
had
amalgamate
lyft
had
envoy
and
people
are
still
continuing
to
use
envoy
today
and
Google
contributed
the
service
control
plane
with
those
three
capabilities
together,
a
steel
was
born
and
I'm
actually
running
a
co-located
event
tomorrow,
where
we're
going
to
be
talking
all
about
hto.
So
if
we're
interested,
there
is
currently
a
wait
list,
but
I
believe
for
the
afternoon
session.
You
guys
should
be
able
to
get
in
if
you're
interested
in
getting
hands-on
and
learning
more
about
is
steel.
A
A
I
still
have
a
minute
and
a
half
so
I'm,
not
sure
what
that
was
about
all
right.
So
the
multi
cluster
capabilities
that
are
coming
out
in
sto
so
far
have
been
experimental,
but
with
the
latest
version
1.4,
they
actually
have
a
CLI
tool
where
you
can
get
started
and
start
playing
with
them
right
now
and
I
want
to
overview
what
that
looks
like
really
quickly.
So
today
you
can
use
cube
CTL
to
connect
up
to
multiple
clusters,
and
you
can
kind
of
see
this
here.
I
get
the
context
and
connected
up
to
three
clusters.
A
Next
I'll
create
a
topology
gamal.
This
is
basically
telling
sto
what
clusters
I
want
to
be
meshed
together
and
then
what
networks
they're
in
so
two
clusters
are
in
the
same
network
and
the
third
one
is
on
a
separate
network
and
finally,
I'll
run
this
experimental
command.
So
it's
toc,
TL
X
for
experimental
Multi
cluster
apply
and
it
will
start
pulling
all
of
those
clusters
together
into
the
same
mesh
and
and
then
it'll
do
some
of
the
heavy
lifting
for
you
to
connect
up
some
of
those
apps
and
services.
A
So,
if
I
deploy
the
same
version
of
an
app
to
all
of
those
clusters-
and
then
I
say
you
know
if
I
kill
one
of
the
services
in
one
of
the
clusters,
it'll
actually
failover
and
and
start
running
those
from
some
of
the
other
ones,
so
very
quickly
to
kind
of
highlight
those
three
capabilities
we
talked
about
on
that
architecture,
diagram
cube
bed
is
doing
that
Federation
capability,
so
automating
resources
and
deployment
of
them
Razzie
is
doing
a
little
bit
of
that.
But
it
has
a
focus
on
visibility
and
seeing
what's
running
where
and
then.
A
Finally,
we
have
sto
that's
solving
that
service
mesh
multi
cluster
layer
between
multiple
clusters.
At
the
end
of
the
day,
it's
important
to
start
thinking
about
your
multi
cluster
strategy.
Today,
if
you're
using
a
Singh,
a
single
cluster
successfully,
chances
are
you're
going
to
mature
and
start
using
more
with
a
unified
control
plane.
You
can
gain
visibility,
see
what's
running
where
you
can
automate
deployments
and
kubernetes
resources
across
multiple
clusters
and
finally,
you
can
manage
network
traffic
between
micro-services.
A
That's
all
the
time
I
have
for
today.
I
hope
this
was
useful,
definitely
check
out
the
Sto
workshop
that
we're
doing
tomorrow
and
if
you're
interested
in
learning
more
about
I
being
plowed
or
maybe
just
kubernetes
cloud
computing
concepts.
Just
open-source
technologies
check
out
our
youtube
channel
on
youtube.com,
slash,
IBM
cloud,
where
you
guys
may
recognize
some
of
the
videos
that
we
put
out
there.
Thank
you
so
much
for
having
me
Sydney.