►
From YouTube: Cloud Jumping with Kubernetes - James Bowes, Manifold
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
Cloud Jumping with Kubernetes - James Bowes, Manifold
Kubernetes promises a degree of freedom from cloud vendor lock-in, providing an API and runtime for containers that most cloud providers support. Beyond the core of container orchestration, there are abstractions for load balancers, persistent storage and autoscaling, to name a few. With this in mind, when Manifold set out to switch cloud providers, we decided to do so by first using as many abstractions in the Kubernetes ecosystem as possible. In this talk, we will explore how Manifold used Kubernetes to migrate between cloud providers. We will look at how to identify cloud specific services and APIs in use in your application, and how Manifold evaluated whether to uplift to a Kubernetes abstraction, translate to the other cloud provider’s service, or keep as is. Finally, we will discuss the challenges and successes of the actual migration between cloud providers.
To Learn More: https://sched.co/GrRg
A
I
think
so
all
right,
hi
everybody.
Thank
you
for
joining
me
today.
After
the
keynotes,
we're
gonna
talk
about
cloud
jumping
with
kubernetes,
so
about
me,
I'm
James,
I'm,
a
technical
lead
at
company
called
manifold.
We
make
a
marketplace
for
developer,
focus,
SAS
products.
Sorry
you
can't
hear
me!
No
audio
is
not
so.
A
That
I
think
might
be
useful
sort
of
similar
subject
matter,
all
right,
so
growing
our
infrastructure,
so
I
just
want
to
start
out
with
with
a
caveat
here.
This
might
be
your
infrastructure
right
lots
of
containers,
real
big.
This
is
ours,
so
we
have
a
relatively
small
infrastructure
right.
We've
got.
A
It's
not
so
much
about
the
the
size,
but
about
the
variety
of
the
workloads
that
you're
dealing
with
you
know
our
we
have
sort
of
a
standard
layout
for
our
micro
service
base
architecture
where
we've
got
one
ingress
and
then
that
connects
with
a
number
of
apps
and
each
each
one.
Most
of
them
sort
of
is
paired
with
a
background
worker.
A
So
why
would
you
cloud
jump
for
us?
You
know,
as
we
were
running
our
infrastructure,
we
moved
to
kubernetes
about
a
year
ago
now,
and
you
know
we
started
to
think
like
okay.
Well,
is
it
about
money
right?
That's
sort
of
one
of
the
big
reasons
is
we
built
our
system
on
top
of
a
cloud
provider?
We
run
our
own
control
plane,
we
run
so
we
run
our
own
host
notes
right
and
if
we
move
to
manage
kubernetes,
we
could
save
some
money
by
not
having
to
run
the
control
plane.
A
Or
is
it
about
saving
time
right,
so
we
actually
spend
a
lot
or
spend
a
lot
of
time,
managing
the
control
plane
and
managing
the
nodes
right,
so
were
we
moving
to
kubernetes
to
like
for
some
purpose
or
what
we're
doing
it
just
to
move
to
kubernetes
and
the
the
purpose
sort
of
has
always
been
to
make
everyone's
lives
easier
and
by
managing
our
own
control
playing
and
managing
our
own
nodes.
You
know
we
added
sort
of
an
extra
layer
of
abstraction
that
we
then
had
to
care
about.
A
So
instead
of
dealing
with
apps
and
infrastructure,
we
were
dealing
with.
You
know,
infrastructure
and
then
a
sort
of
kubernetes
layer
and
then
our
apps
or
is
it
about?
You
know
dependability
and
reliability
in
running
our
own
system?
You
know,
as
as
we
sort
of
took
on
more
load,
we
started
to
experience
stress
around
the
edges,
particularly
like
at
the
networking
layer.
It's
like
we've
configured
this,
but
do
we
really
care
about
it?
Not
so
much
because
we're
just
worried
about
our
applications,
but
I'd
say
the
main
thing
for
us
was
just
about
time.
A
Right,
like
we
didn't,
want
to
spend
all
this
time
managing
our
own
control
plane.
We
like
the
features
that
kubernetes
gives
us,
but
we
don't
want
to
be
in
the
business
of
managing
kubernetes
ourself,
so
we
did
a
little
comparison
right
and
we
are
on
AWS
on
a
or
on
a
sort
of
you
know
self
built
system
and
the
biggest
thing
that
sort
of
stands
out
for
us
with
GCP
was
having
much
more
like
managed.
A
Everything
right
and
Xero
has
sort
of
similar
things
where
you
don't
have
to
care
so
much
about
the
nodes,
which
is
good
so
first
talk.
I
wanted
to
point
out.
Is
this
one
which
looks
really
great,
and
you
know
so
we
can
all
sort
of
take
a
lesson
to
vote.
You
know
maybe
we're
focusing
on
the
wrong
thing
if
we
want
to
deliver
applications
and
we're
spending
all
of
our
time
delivering
a
cluster
that
might
be
their
own
focus.
A
So
the
first
tip
is
that
you
know
cloud
jumping:
isn't
there
doesn't
have
to
be
multi
or
hybrid
cloud,
we're
not
looking
at
having
a
long-running
multi
cluster
set
up
here.
So
that
means
that
we'll
be
making.
We
are
have
made
different
choices
about
what
exactly
we're
going
to
do
right.
If
you're
doing
a
migration,
then
maybe
you're,
okay
with
doing
Robin
DNS
for
like
a
day
or
two,
but
for
a
longer
live
setup.
A
It's
still
under
construction,
and
that
is
because
migrating
between
cloud
providers
is
hard.
We
started
many
months
ago,
you
know
and
we're
still
going
because
other
things
come
up
and
maintaining
the
existing
cluster
was
taking
away
from
the
resources
that
would
be
doing
the
migration
yeah.
But
we're
gonna
talk
a
bit
about
how
kubernetes
can
help
with
this.
You
know,
and
it
does
still
help
it-
does-
make
it
better
than
starting
from
from
scratch.
So
yeah,
big,
tip
here
and
sort
of
a
humbling
thing
is
to
get
help
right.
A
A
A
It
was
glorious
right,
you
could
run
terraform
apply
and
it
would
bring
everything
up
from
from
scratch
and
you'd
go
from
having
no
system
to
all
of
your
code
running.
You
know
the
latest
sort
of
deployment
version
and
then,
as
we
moved
to
kubernetes,
we
maintained
that
existing
terraform
sort
of
defined
our
VPC
and
then
we've
brought
in
cops
to
set
up
our
cluster
itself
and
to
deploy.
A
So
as
we
defined
our
different
environments,
you
know
we
sort
of
follow
the
examples
and
make
a
bunch
of
llamó.
Then
you
end
up
with
a
you
know
several
directories
of
duplicated
definitions,
and
it
would
have
been
much
better
if
we
had
brought
in
some
extra
tool
to
sort
of
help,
D
duplicate,
that
across
environments,
so
yeah.
A
Another
talk
here,
customized
is
that
what
we're
looking
at
to
djibouti
o'clock
across
environments-
and
this
might
be
a
good
talk
to
attend
on
that,
so
the
parts
that
you
get
for
free
to
help
you
with
your
migration
is,
you
know
the
kubernetes
api
and
it
can't
really
be
understated
that
the
fact
that
there
is
a
way
to
that
is
supported
by
the
major
cloud
providers
to
do
deployments
of
your
code
and
it's
common
across
all
of
them.
You
know
so
we
have
our
deployments
in
the
stateful
sets
and
in
jobs
as
well
right.
A
So
another
tip
is
to
put
your
trust
in
kubernetes.
Again.
Sort
of
part
of
the
common
API
years
is
like
network
policy
for
defining.
You
know
your
boundaries
between
services,
as
we
were,
defining
our
cluster.
It
felt
you
know
very
scary
for
me
to
not
have
something
at
a
lower
level,
but
it's
worked
out
fine,
and
this
is
a
primitive
that
we
can
port
between
cloud
providers
so
by
into
the
ecosystem
right.
There's
all
these
other
parts
that
are
sort
of
central
and
then
secondary
to
kubernetes.
That
can
help
you
with
your
with
your
migration.
A
So
you
know
it.
Ingress
is,
of
course,
are
a
very
sort
of
centralized
part
here
that
will
help
but
like
relying
on
certain
manager,
an
external
DNS,
so
you
bring
handle
your
SSL
or
TLS
automatically
with
certain
manager
and
use
external
DNS
to
sort
of
automatically
create
DNS
that
you
need
for
different
environments
and
then
there's
a
bunch
of
other
sort
of
additional
controllers.
You
can
use
we've
written
our
own
to
sort
of
handle
health
checks.
A
The
advantage
of
having
this
in
your
cluster
is
sort
of
comes
back
to
the
the
separation
between
the
infrastructure
layer
and
the
application
layer.
So
if
you're
configuring,
something
like
cert
manager
or
external
DNS
sort
of
in
your
infrastructure
layer
and
then
through
annotations
or
CR
DS
or
whatever
the
system
uses
to
like
sort
of
take
advantage
of
it,
you
know
your
application
developers
don't
need
to
worry
about
the
lower
part,
and
they
can
sort
of
use
this.
A
Why
this
matters
is
that
most
of
these
tools
assume
a
single
cluster.
So
if
you've
got
your
system
set
up,
if
your
primary
DNS
pointing
at
this,
you
know
one
Engler
ingress
in
your
cluster
you're,
going
to
be
needing
to
do
some
DNS
fiddling
as
you
migrate.
So
if
you've
got
it
set
up
like
this,
you
can
just
disable.
A
This
is
sort
of
a
big
part
ideas.
Try
as
hard
as
you
might,
there's
always
going
to
be
some
amount
of
application
code
that
is
using
specific
sort
of
api's
from
your
cloud
provider.
So
things
like
object,
storage,
like
s3,
you
know,
or
some
kind
of
message,
passing
or
queues,
or
you
know
a
Michigan
learning,
workflow
and
sorry
there's
not
too
much.
A
You
can
really
do
about
that
right,
not
yet
in
the
same
way
that
kubernetes
is
sort
of
democratized
deployments
and
envoy
and
to
some
degree
SEO
is
sort
of
doing
the
same
for
the
networking
layer.
You
know
hopefully
some
day,
we'll
see
K
native
and
cube
flow
or
something
similar
in
a
place
where
you
can
have
a
managed
version
from
a
cloud
provider.
So
you
know
which
is
important
for
us
is
not
having
to
worry
about
managing
it,
but
also
being
able
to
rely
on
this
API
across
providers.
A
A
A
A
This
is
a
good
way
to
start
sort
of
testing
out.
You
know
your
your
migration
to
a
different
provider.
Does
your
cluster
actually
work?
Is
there
some
like
API,
that
you
thought
you
weren't
using
in
this
service,
but
you
are,
but
it's
also
a
great
place
to
finish
I'd
so
sort
of
if
it's
not
important,
leave
it
to
the
end.
A
But
the
thing
that
sort
of
is
has
been
hard
to
to
accept
for
me
is
that
you
don't
really
have
to
migrate
everything
again.
If
the
point
is
to
make
it,
you
know,
if
we're
looking
to
save
time,
you
know
or
money
as
well,
and
the
point
is
not
just
to
use
kubernetes
and
we
can
leave
some
workloads
in
the
old
cloud
or
we
can
run
them
elsewhere.
A
Fortunately,
we
are
able
to
do
over
the
public
sort
of
over
the
internet,
so
hasn't
been
too
bad
there
for
us,
so
we're
actually
coming
to
the
end,
but
I
do
need
to
talk
about
the
elephant
in
the
room,
which
is
data
and
state
and
Postgres
for
us
right.
This
is
sort
of
the
the
big
thing
about
moving
between
any
cloud
service
is:
what
do
you
do
with
your
data?
A
Some
of
that
limitation
may
come
from
the
hosts
of
your
like
current
manage
provider.
Some
of
it
may
be
where
you're
moving
to
for
us
I
believe
it's
where
we're
going
versus
where
we
are.
But
again
this
is
a
great
place
to
look.
You
know
to
engage
with
professional
services.
This
is
sort
of
the
the
same
story
that
we've
been
telling
for
a
long
time
for
migrating
data,
and
you
know
as
much
as
you
might
not
do
maybe
make
as
much
as
you
might
not
want
to.
A
There's
a
lot
of
other
state
and
data
that
you'll
have
in
your
applications.
So
if
we
look
at
what
our,
what
we're
running
you
know,
you'd
be
find
these
sort
of
places
where
there's
tiny
data,
there's
services
that
setup
semi,
persistent
like
caching
for
other
services
or
one
service,
that
is,
writing
data
for
another
service
to
read
and
there's
a
few
things
that
you
can
use
kubernetes
for
and
help
with
this.
A
So
the
first
thing
is
shared
ephemeral
volumes
in
pots.
You
know
you
may
have
two
separate
services
running
where
one
is
writing
this
cache
for
the
other
one
like
if
you're
just
first
serving
like
a
website
and
you're
periodically
refreshing
it
you
could,
then
instead
you
could
convert
those
to
being.
A
The
other
tip
is
to
try
mounted
config.
Maps.
Excuse
me
so
in
this
case,
like
we
have
a
system
that
is,
writing
data
for
another
service
to
consume.
So
it's
always
uni-directional
like
that
and
before
we
were
doing
this
as
a
you
know,
writing
to
to
disk
and
then
reading
from
disk
in
the
Cepheid
service,
but
changing
that
first
service
to
actually
rely
on
config,
Maps
and
speak
to
the
kubernetes
api
and
let
us
sort
of
modify
that
first
service.
A
A
This
talk
is
going
to
bring
up
federated
and
stretch
volumes
with
to
sort
of
migrate
across
across
cloud
providers,
and
that
can
be
pretty
crazy,
so
almost
done
here,
but
I
did
want
to
give
a
preview
first
for
a
talk
form
from
my
coworker
Elmer,
who
will
be
speaking
tomorrow
on
deploying
rock-solid
applications
with
kubernetes.
So
if
you
want
to
learn
about
making
sure
that
your
pods
are
actually
running
on
on
different
nodes,
when
you
want
them
to
be
or
setting
up
network
policies,
you
can
check
out
his
talk.