►
From YouTube: Exploring Application Portability Across Public Cloud Providers Using K8s - Erin Boyd & Ivan Font
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
Exploring Application Portability Across Public Cloud Providers Using K8s - Erin Boyd & Ivan Font, Red Hat
Application portability across hybrid clouds is a cornerstone of application deployment strategies. Kubernetes offers a vital abstraction across cloud providers’ infrastructure for using multiple clusters, but up until now there has not been a native Kubernetes experience for managing your clusters. With the advent of Kubernetes multi-cluster features such as Cluster Registry and Federation-v2, we now have a registry to store all your cluster endpoints with a control plane to support managing and migrating your applications across your hybrid cloud infrastructure. But what about your data? There’s a solution for that too in the shape of federated and stretch volumes. Come learn how Kubernetes multi-cluster features combined with federated & stretch volumes are used to migrate a simple reference application across public cloud providers.
To Learn More: https://sched.co/GrWH
A
B
A
Right,
my
name
is
Aaron
Boyd
I'm
contributed
to
kubernetes
I
work
in
the
office
of
the
CTO
for
Red
Hat
and
an
interesting
thing
about
me.
This
was
me
40
minutes
ago
in
the
speaker's
lunch
cuz.
We
just
got
our
demo
working,
so
yes,
very
excited
so
pray
that
it's
still
working
now
that
we've
switched
over
to
a
different
Wi-Fi.
B
Right
so
show
of
hands
how
many
of
you
have
heard
of
Federation
version
2
in
kubernetes,
okay,
few
you
out
there
so
I
won't
go
into
too
much
detail
here.
But
if
you're
interested
in
more
details,
we
do
have
a
cig,
multi
cluster,
deep
dive
session
on
Thursday
morning
at
10:50
that
I
encourage
you
all
to
go
to.
So
what
is
Federation?
Well,
it's
the
ability
to
manage
n
non-homogenous
kubernetes
clusters.
B
These
could
be
clusters
in
public
cloud,
private
cloud,
basically
any
kubernetes
cluster
that
you
have
the
API
server
access
information
to,
and
so
it
basically
allows
you
to
synchronize
your
resources
across
all
of
these
clusters.
It
also
enables
high
availability-
and
it
does
that
by
basically
allowing
you
to
distribute
your
resources
onto
different
clusters,
and
so
you
don't
have
a
single
point
of
failure
in
any
single
cluster.
B
It
also
enables
freedom
of
choice
and
basically
it
allows
you
to
freely
to
move
your
application
on
to
any
cluster
that
you
have
and
it
really
reduces
the
burden
to
doing
that.
So
what
do
you
get
with
the
Federation
version?
Two
that
we
have
today?
Well,
it's
a
CR
D
based
Federation
API,
so
you
get
a
native
kubernetes
experience.
You
can
talk
directly
to
the
kubernetes
api
server
in
the
host
cluster,
that's
hosting
the
Federation
control
plane
and
you
can
configure
the
control
plane
directly
through
that.
B
B
You
also
get
the
ability
to
specify
overrides,
so
you
can
have
field
level
overrides
by
specifying
some
sort
of
difference
from
one
cluster
to
another.
So,
for
example,
if
you
have
like
deployments-
and
you
want
to
specify
replicas
difference
in
replicas
from
one
cluster
to
another-
you
can
do
that
via
overrides
and
we'll
see
a
little
bit
of
that.
B
You
also
get
the
ability
to
specify
placement
decisions,
so
you
can
provide
these
placement
directives
that
dictate
where
you
want
your
resources
placed
in
your
set
of
clusters
in
your
Federation,
and
we
support
basically
a
list
of
clusters
or
a
label
based
selector
on
your
clusters,
if
you
categorize
them
and
label
your
clusters.
That
way,
we
also
have
dynamic
scheduling.
B
So
you
can
basically
four
replicas
or
deployments
specify
a
certain
number
of
max
replicas
and
you
can
provide
preferences
and
rules
to
distribute
those
set
of
replicas
amongst
your
Federation
in
any
particular
way
that
you
want
and
then
lastly,
across
cluster
service
discovery,
basically
gives
you
the
ability
to
discover
your
services
across
clusters.
It's
a
DNS
based
mechanism,
and
it
does
that
via
federated
services
and
federated
ingress,
along
with
a
project
called
external
DNS.
That
allows
you
to
program
various
different
DNS
Reiter's.
B
So
what
one
of
the
things
Federation
enables
is
application
portability,
and
so
we
define
that
as
these
use
cases
here,
which
is
basically
having
the
ability
to
move
your
application
and
perhaps
its
data
onto
a
different
cluster,
and
this
is
kubernetes
clusters.
Of
course,
also.
The
ability
to
burst
your
application
on
to
multiple
clusters,
depending
on
like
workload,
demand
as
well
as
possibly
removing
a
cluster
or
failing
over
by
removing
it
from
the
Federation
and
having
like
zero
downtime
for
your
application
and
so
now
I'll
hand
it
over
to
Aaron
to
talk
about
the
data.
B
A
So
storage
is
arguably
one
of
the
most
sticky
parts
of
migrating
applications
across
clusters.
So
we've
come
up
with
what
we
think
are
kind
of
the
general
patterns
around
migrating
data.
So
the
first
one
is
stretched.
This
is
kind
of
a
word.
We
came
up
with
it,
Red
Hat,
that's
just
how
we
envision
it
in
our
head,
but
it's
the
ability
to
take
one
single
volume
and
stretch
it
across
the
Federation,
meaning
I
have
a
single
volume,
that's
accessible
from
AWS,
GCE
and
Azure
all.
A
At
the
same
time,
we
have
also
a
pattern,
a
geo,
sensitive
or
cloud
specific.
So
if
you're
running
a
high-performance
application,
you
may
want
to
use
a
federation
pattern
to
keep
that
type
of
persistent
volume,
that's
native
to
that
cloud
or
the
default
storage
class.
As
what
you're
going
to
store
your
data
within
and
we'll
actually
show
you
that
within
our
demo,
the
next
one
is
containerized
storage.
A
So
for
software-defined
storage
are
a
couple
different
options
in
the
kubernetes
ecosystem,
where
we
can
actually
have
containerized
storage
within
kubernetes
and
with
that
we
can
actually
federates
us
towards.
Although
we've
only
got
it
working
in
a
homogenous
set
of
AWS
clusters,
you
can
actually
deploy
a
federation
application.
Have
it
create
the
storage
on
the
clusters
that
you're
going
to
at
the
same
time?
And
this
affords
you
the
ability
to
have
a
single
control
plane
with
both
your
application
and
data,
which
is
really
slick
and
then
the
last
one?
A
Last
but
not
least,
there's
always
brownfield.
Not
everything
is
green.
We
talked
about
a
control
plane
where
you
leave
the
data
in
place.
Now
this
isn't
an
ideal
situation
but
I
think
in
kubernetes.
You
know
we
try
really
hard
within
the
storage
saying
not
to
dictate
how
you
should
do
something.
We
should
just
be
exposing
the
ways
that
you
can
and
it
might
be,
that
in
your
enterprise,
you
want
to
leave
the
data
in
place.
A
You
have
a
private
cloud,
it's
sensitive
data
and
there's
no
way
you
want
to
migrate
that
to
the
cloud,
but
you
want
to
expose
the
application
itself,
storing
the
data
locally
Federation.
The
last
pattern
allows
you
to
do
this.
You
can
leave
your
data
base
in
place
on
your
private
cloud,
still
run
your
application
in
the
public
cloud
and
ride
the
data
back.
B
All
right,
so,
let's
take
a
look
here
and
let's
show
you
the
current
state
of
things
here.
So
what
we
have
is
a
set
of
kubernetes
clusters.
We
have
a
cluster
running
on
AWS,
GCP
and
Azure,
and
we've
deployed
the
Federation
control
plane
on
to
the
GCP
cluster
specifically,
and
we've
deployed
containerized
MongoDB
on
to
each
of
the
clusters
with
the
Federation
control
plane
and
we
we
deployed
containerized
MongoDB
and
we
created
a
replica
set
so
we're
replicating
data
within.
B
We
then
took
a
reference
application
like
pac-man
and
we
containerized
it
it's
not--
based
on
nodejs,
and
we
deployed
that
through
the
Federation
control
plane
as
well,
and
we
have
that
running
right
now
on
AWS
and
GCP,
so
I'm
going
to
transition
to
the
turn.
While
here
and
on
the
right,
you
will
see
the
list
of.
Let
me
increase
that
a
little
bit.
B
All
right
so
on
the
right,
you
can
see
that
we
have
a
watch
running
on
each
of
the.
Let
me
expand
that
a
little
bit.
We
have
a
watch
running
so
that
you
can
see
the
pods
in
each
of
the
clusters
and
on
the
top
you
can
see
we
have
the
GCP
cluster
and
it's
running
five
instances
of
pac-man
there
and
we
have
the
AWS
cluster
here
and
it's
running
three
instances
of
pac-man
and
we'll
talk
a
little
bit
about
the
differences
there.
But
let
me
show
you
the
configs
that
were
involved
in
deploying
this.
B
Similarly,
we
have
a
federated
deployment
override
and
if
you
are
wondering
why
the
gke
cluster
here
shows
5,
pods
and
AWS
only
shows
3.
It's
because
we
have
this
federated
deployment
override
API
that
we
basically
can
list
a
set
of
overrides.
So
on
the
AWS
cluster
here
we're
wanting
to
override
these
spectra
placards
and
we
specify
the
value
of
3.
So
we
only
have
three
pods
running
in
AWS
and
the
default
is
5
for
anything
else.
B
And
then
we
have
the
federated
deployment
placement
resource
here
and
it
basically
provides
the
list
of
clusters
where
we
want
to
federate
this
resource.
And
here
you
can
see
that
we've
listed
our
Google
Cloud
cluster
and
the
AWS
cluster,
and
this
could
similarly
be
a
label
selector.
If
you
had
labels
on
your
clusters.
B
So
feel
free
to
play
along
on
your
laptops
or
Android
devices,
but
I'll
show
you
up
live
here
in
case
you
don't
have
a
compatible
device.
So
the
cloud
here
you
can
see
that
we're
running
on
Google's
cloud
and
some
other
print
information
like
the
zone
and
the
host.
So
similarly,
here
on
the
right,
you
can
see
kind
of
a
live
stats
being
updated
as
folks
are
playing
and
I'll
go
ahead
and
play
around
here.
C
B
Trying
to
collect
some
score
here
and
let's
say
that
as
Ivan
won,
and
we
can
view
the
high
score
here
and
we
see
that
Ivan
won.
What's
persisted
running
on
Google's
cloud,
with
a
high
score
of
370
and
refresh-
and
you
can
see
now
we're
on
the
AWS
cloud
here
we
have
a
load
balancer,
that's
just
performing
round-robin
across
the
different
clusters
and
you
can
basically
play
on
both
cloud
providers.
So,
let's
play
another
round
here.
C
B
C
B
B
B
And
there's
GCP
and
we
can
look
at
the
high
scores
there
and
we
can
see
that
the
same
scores
persisted
alright,
so
we're
running
on
all
three
cloud
providers
pretty
easily,
and
so
let's
go
ahead
and
decide
for
some
reason.
Whatever
reason
you
have,
we
want
to
migrate
away
from
AWS
and
just
be
running
on
Azure
and
GCP.
B
B
A
So
what
you
didn't
really
see
with
storage,
which
you
shouldn't
see
right
storage,
should
just
be
easy.
It
should
just
work.
So
when
we
originally
dreamed
up
this
demo,
we
thought
it
would
be
really
cool
if
I
used
one
storage
provider
for
everything
that
I
wanted
to
do
in
my
cluster.
So
we
wanted
to
put
our
stretch
volume
on.
We
wanted
to
use
our
stretch
volume
for
our
logs.
Well,
that
didn't
quite
work
out
the
way
we
wanted
to
work
similar
to
this
I.
A
A
A
So
I
kind
of
call
this
my
tinfoil
hat
pattern.
So
if
you're
super
paranoid
that
you're
gonna
lose
the
data
and
it's
that
important
and
you
feel
like
you
need
to
double
replicate
something
then
sure
it
does
work.
We
got
it
working,
but
probably
not
the
best
pattern.
It's
expensive
and
unnecessary
double
replication
doesn't
equal
double
prizes.
So
what
could
we
use?
Our
stretched
volume
with?
Where
does
that
feel
like
it
fits
into
this
whole
Federation
pattern?
And
what
did
we
end
up
doing
so?
A
What
we
ended
up
doing
was
actually
pretty
clever,
so
we
took
on
each
cloud
provider
using
its
default
storage
class,
so
AWS
we
use
an
EBS
volume
at
GCE.
We
used
a
PD,
we
were
able
to
federate
and
just
say,
create
me
a
PV,
PV,
C
combination
bind
it
and
use
that
storage
type
that
you
natively
use
and
I
don't
have
to
worry
about
it.
It
just
works
is
I
even
showed
us.
A
The
high
scores
are
still
propagated
and
replicated
completely
across
because
that's
what
does
best
and
we're
just
gonna,
let
do
its
thing,
but
then
we
wanted
to
highlight
what
Federation
affords
to
something
like
a
stretch
volume.
So
what
we
did
is
we
ended
up
stretching
our
logs
across
that,
so
we
were
able
to
take
the
logs
that
produces
from
each
of
the
instances
and
write
it
to
a
single
volume.
So
everyone's
counting
on
who
cares
about
logs,
probably
a
lot
of
DevOps
people
care
about
logs.
B
So
I'm
gonna
ssh
to
the
instance
here
running
on
GCE
and
I'm
going
to
CD
into
the
amount
point
that's
hosting
these
logs
and
you
can
see
that
we
have
the
logs
running
for
each
of
the
cluster
instances
in
each
of
the
cloud
providers.
So
you
can
see
aks
here
for
Azure
gke
here
for
GCP
and
ec2
here
for
AWS
and.
A
Even
though
we
killed
a
W
AWS
instance
again,
it's
persisted
it's
still
there.
It's
not
updating
like
the
others,
but
the
data
is
still
there
and
available.
So
if
you
do
have
a
critical
application,
you're
trying
to
debug
that
dies
in
one
of
your
federated
clusters,
you
then
still
have
accessibility
to
that
log
from
anywhere
to
be
able
to
fix
your
problem.
So
that
is
our
demo
and
it
actually
works.
A
B
A
The
reason
why
we
scaled
to
a
different
cloud
is
just
to
show
the
flexibility
of
the
Federation
control
control
plane.
So
there's
a
lot
of
like
what's
the
difference
between
multi
cloud
and
multi
cluster
right,
so
we're
trying
to
highlight
that
it's
multiple
clusters
on
multiple
clouds,
so
it
affords
you
the
flexibility
to
be
able
to
have
that
choice
that
something
went
wrong
on
AWS
and
I
want
to
scale
it
up
on.
You
know
GK.
So
no
other
reason
than
just
to
show
the
flexibility.
I
guess.
Does
that
answer
your
question.
A
D
B
Well,
you
were
using
a
cluster
registry
and
a
resource
called
federated
clusters
which
basically
provides
auerbach
credentials
to
the
control
plane
itself
to
be
able
to
create
and
modify
the
resources
necessary
in
each
cluster.
If
you
wanted
to
provide
more
fine-grained
control,
you
could
federate
your
arbok
resources.
However,
you
see
fit
so
you
would
define
them
and
distribute
them
through
the
Federation
control
plane.
However,
you
want
to
define
your
resources,
so
you
can
fetter
eight
like
service
accounts,
cluster
roles,
cluster
role,
bindings
and
that
type
of
stuff,
as
well.
A
B
Well,
it's
actually
using
a
service
load,
balancer,
that's
accessible
across
the
public
Internet,
not
necessarily
something
you
want
to
do
for
security
reasons.
We
are
looking
into
other
networking
facets
of
this
problem,
where
perhaps
we
can
tunnel
traffic
between
clusters,
but
there's
definitely
a
lot
of
networking
use
cases
that
we
need
to
consider
as
we
continue
to
evolve
this
project.
A
Yep,
so
the
stretched
volume
is
still
using
kubernetes
primitives,
it's
still
tied
together
with
that
pod
through
a
PV,
PV
C
claim.
So
when
we
set
up
the
log,
we
just
told
it
to
write
to
this
persistent
volume
claim
so
above
everything
else.
It's
still
using.
You
know
kubernetes
api
primitives
to
be
able
to
define
these
resources
so
they're
they're,
one
in
the
same
you're
welcome,
go
ahead.
E
B
We're
not
using
a
network
overlay
I
think
the
question
is
like
how
do
you
handle
upgrades
through
the
Federation
control
plane?
That's
a
very
challenging
use
case
that
we
need
to
consider
as
we
go
forward,
we're
still
in
the
alpha
stage.
So
we
do
have
a
pretty
strict
requirement
that
the
clusters
need
to
be
at
least
at
the
version
of
the
host
cluster,
which
is
1.11
right
now,
but
as
we
continue
to
progress
and
evolve
the
API
and
eventually
hit
beta,
we
need
to
start
considering
the
aspects
of
upgrades.
B
There
is
cross
cluster
communication
because
the
cube
API
server
in
each
of
the
clusters
is
available
on
the
public
Internet.
As
long
as
your
credentials
are
set
up
appropriately,
you
can
access
and
configure
the
cluster
and
the
control
plane.
The
Federation
control
plane
itself
can
access
the
cube
API
server
in
each
of
those
clusters.
Great
question
yep.
B
So
the
question
is:
how
does
Federation
relate
with
things
like
Sto?
We
actually
have
interest
in
the
community
on
federating
sto
itself,
so
there
was
actually
a
presentation,
I
believe
earlier
today
for
the
cig,
multi
cluster
intro,
where
sto
itself
was
being
federated
using
the
Federation
control
plane.
So
you
can
think
of
the
Federation
as
this
very
low
level
set
of
primitives
that
can
be
built
on
top
of
and
you
can
Fedder
eight
other
higher
level.
Applications
like
sto
in
this
example.
B
A
good
question:
are
there
any
latency
considerations
with
the
deployments
in
each
of
the
clusters?
You
know
where
the
Federation
control
plane
is
kind
of
needing
to
access
these
clusters
that
are
spanned
across
different
regions.
Yes,
I
accept
it's
a
declarative
API,
so
all
it's
doing
is
really
just
making
sure
that
that
resource
matches
what
you're
requesting.
So
there
isn't
necessarily
like
continuous
sort
of
latency
aspect
that
needs
to
be
considered.
A
But
it
is
one
of
the
pitfalls
right
of
Federation
is
the
expectation
that
you're
going
to
have
a
certain
network?
You
know
performance
baseline
that,
especially
with
storage.
You
have
to
consider
and
distributed
storage.
So
you
know:
you're
gonna
have
probably
near
real-time
an
eventual
consistency,
but
you're
not
going
to
have
that
right
out
of
the
gate,
depending
on
your
network.
So
I
mean
that
is
a
consideration
and
that's
something
to
consider.
If
you
decide
to
go
through
Federation
as
what
kind
of
network
bandwidth
am
I,
gonna
have
right
and
then
the
ability
to
switch.
A
You
know
the.
But
again
the
design
allows
you
to
switch
like.
Let's
say
that
zone
is
really
slow
or
you
have
your
cluster
federated
somewhere
and
you
can
bring
it
closer
to
where
it
is
I
mean
you
can.
You
know,
switch
zones
as
you
have
to
if
there's
Network
latency
problems,
because
I
have
seen
that
I
have
seen
where
there's
you
know,
bursting
and
latency,
depending
on
what
cloud
you're
in
and
what
geography.
B
So
one
of
the
things
to
consider
too
is
the
h.a
aspects
of
the
Federation
control
plane
itself,
and
there
are
at
CD
latency
restrictions
that
really
inhibit
the
ability
to
kind
of
provide
an
H,
a
Federation
control,
plane
itself.
This
mechanism
uses
a
push
reconciler
where
you're
running
the
controller
inside
of
the
host
cluster,
and
it's
actually
pushing
resources
to
multiple
clusters
to
kind
of
get
around.
B
Some
of
that
there's
potential
for
introducing
like
a
pull
reconciler
mechanism,
where
you
have
controllers
running
in
each
of
the
clusters
themselves,
to
kind
of
provide
some
of
that
h.a
aspect
and
then
they're
pulling
from
kind
of
a
in
repository
or
something
like
using
it.
For
example,
question
over
here.