►
Description
"Stateful workloads are a challenge. Kubernetes, containers, and a number of other cloud native technologies are built on the assumption of ephemeral workloads.
That means a lot of extra work goes into making databases, and other stateful components work on Kubernetes. One source of extra work is that apps are often made of multiple components. Apps have statefulSets, Services, PVs, and a number of other resources that when composed together, define them.
The second source of extra work is that every app has its own procedure for getting backed up (and restoring). App-data management simplifies these problems. That’s two big ideas. One is that the parts that make up an app should be stored along with snapshots. The next is that with the right snapshot technique, most apps can share the same procedure for backing up and restoring.
This talk demos Jenkins being cloned. We’ll discuss how programmatic APIs could potentially enable more robust CI and testing for stateful workloads in the cloud."
A
Part
of
that
journey
is
going
to
be
talking
about
how
netapp,
where
we
exist
in
the
cloud
native
space
and
how
we
view
where
things
are
going
in
the
future
and
how
we
plan
to
contribute
to
that
view
of
the
future,
how
we
want
to
shape
things.
So,
let's
get
started
with
what
netapp
is
and
our
presence
on
the
cloud
you
may
have
seen
us
around
major
cloud
providers
providing
something
called
cloud
volumes.
This
is
a
service
that
provides
enterprise
grade
sort
of
storage.
So
it's
high
performance.
A
A
We
serve
many
of
the
global
2000
companies
and
we've
seen
their
interest
in
cncf
and
cloud
native
projects
sort
of
balloon
in
the
recent
years
that
those
have
also
sort
of
been
growing-
and
that's
led
to
some
projects
like
trident
here
so
trident
is
a
great
example
of
an
open
source
project
from
netapp
and
trident
simplifies
connecting
your
storage
to
your
kubernetes
cluster.
So
trident
can
take
any
netapp
storage
source
and
you
know,
offer
it
up
to
a
container
anything
running
on
kubernetes
or
docker.
A
That
work
has
involved
us
contributing
some
work
to
the
upstream
container,
storage
interface
or
csi,
and
we
work
across
all
major
platforms.
Basically,
so
trident
is
something
you
can
try
out
right
now:
it's
free
open
source
on
github.
This
solves
a
big
problem
when
it
comes
to
connecting
your
storage
to
containers
which
are
otherwise
ephemeral.
A
What
we've
seen
from
the
people
who've
adopted
trident
so
far,
is
there's
about
600
organizations
that
are
sharing
usage
data
with
us
and
across
those
organizations
there's
over
six
petabytes
of
data
in
management
under
trident,
and
we
we
think
that
number
is
going
to
continue
to
grow
as
more
companies
figure
out
how
to
simplify
and
really
start
to
enjoy
the
benefits
of
running
stateful
programs
on
top
of
kubernetes,
that
isn't
to
say
that
there
aren't
challenges
that
go
along
with
that.
There's
other
projects
that
mix
and
match
trident,
with
open
source
solutions
like
kubeflow.
A
This
is
netapp's
ai
control
plane.
This
does
some
really
great
things
in
terms
of
simplifying
how
to
get
an
aiml
pipeline
up
and
running,
but
some
challenges
persist
even
after
you
look
at
solutions
like
this,
so
our
premise
here
is
that
we
think
kubernetes
is
ready
for
data,
but
in
order
to
get
kubernetes
ready
for
data,
we
have
to
solve
two
key
big
challenges.
The
first
challenge-
that's
sort
of
represented
in
the
subtext
here-
is
that
you
know
a
basic
stateful.
A
Application
on
top
of
kubernetes
is
comprised
of
multiple
components,
so
even
the
simplest
application.
Something
like
a
wordpress
wordpress
is
essentially
just
php
in
a
database
that
winds
up
being
a
dozen
or
so
different
yaml
manifests
that
are
deployed
to
kubernetes,
and
you
know
a
multitude
of
resources
spawn
from
that.
We'll
look
at
that
in
just
a
little
bit
as
an
example
of
how
complex
things
can
be,
so
there's
a
need
to
deal
with
an
application
as
a
logical
unit,
even
though,
when
the
application
is
deployed,
it's
represented
by
multiple
different
resources.
A
A
So
we'll
take
a
look
at
wordpress
running
on
top
of
kubernetes
as
just
a
standard
application
to
showcase
some
of
the
challenge
there
and
then
we'll
dive
into
a
project
astra
demo,
which
is
our
vision
for
how
we
think
things
are
going
to
change
and
be
simpler
in
the
future.
With
kubernetes,
we
can
make
things
easy
for
our
wordpress
install
by
using
helm,
which
is
a
quite
accessible
way
to
install
applications
on
top
of
kubernetes.
A
A
In
the
case
of
taking
a
snapshot,
there
are
probably
particular
details,
particular
configuration
settings
that
are
stored
on
the
kubernetes
cluster
that
are
relevant
to
that
snapshot
as
well.
So,
in
order
to
take
a
good
backup,
that's
easy
to
restore.
We
want
to
package
that
snapshot
along
with
that
metadata
about
those
settings
running
on
a
kubernetes
cluster,
and
that's
just
what
we
call
our
backup
and
snapshot
process
here.
A
So
the
application
that
we're
looking
at
is
project
astra.
This
is
an
alpha
at
the
moment
and
if
you're
interested
in
getting
involved
in
the
beta
program,
I'll
be
sharing
a
link
at
the
end
of
this
presentation
that
can
help
you
get
acquainted
with
that.
But
for
now
let's
just
click
in
and
take
a
look
at
the
applications
that
are
running
on
our
clusters.
So
we
have
a
legacy
db
here.
It's
just
a
standalone
postgres
instance.
A
I
could
click
into
that
and
see
metadata
about
how
that's
running.
So
I
can
see
that
that
is
indeed
a
postgres
instance.
Likewise,
I
can
click
into
prod
us
central
and
see
that
it
is
running
a
jenkins
chart.
So
this
is
a
jenkins
helm
chart
this
tab
that
we're
looking
at
here
is
the
storage
tab.
So
I'm
seeing
information
about
the
persistent
volume
claim
and
the
size
of
storage
that
we
have
here.
So
this
is
live
data
about
how
the
application
is
running
in
production.
A
At
the
moment,
part
of
the
value
of
using
a
cloud-based
service
like
cloud
volumes
from
netapp
is,
you
can
easily
add
storage
to
the
cluster.
If
you
need
it
or
you
can
change
the
kind
of
storage
class,
the
tier
of
service
that
you're
getting
with
your
application
relatively
easily.
So
if
we
needed
to
add
another
10
terabytes
or
another
100
terabytes
it'd
be
relatively
simple
for
us
to
scale
things
up
and
down
here.
A
Other
tabs
will
show
other
information.
So
these
are
some
point
in
time
snapshots
that
we've
taken
in
the
past
relatively
recent
past.
If
you
look
at
those
created
dates
there,
but
this
makes
it
easy
to
take
a
snapshot.
If
we
need
another,
we
can
literally
just
click.
This
create
a
snapshot
button.
There
are
other
avenues
for
making
that
snapshot
on
other
pages,
which
we'll
show
you
in
a
second,
but
all
that
is
to
say
that
you
want
sort
of
a
clockwork
system
in
some
way.
A
That's
going
to
capture
snapshots
for
you
and
give
you
an
application
that
you
can
easily
rehydrate
or
move
around,
give
you
peace
of
mind
that
your
data
is
protected,
but
also
make
it
easy
for
you
to
restore
that
snapshot
and
test
that
it
works.
That's
sort
of
the
whole
dream
that
we're
chasing
after
here.
A
Finally,
let's
take
a
look
at
the
overview
tab,
so
this
contains
information
about
that
metadata
that
we
talked
about.
So
we
are
running
a
jenkins
instance,
which
is
a
little
bit
different
than
wordpress
jenkins,
for
instance,
stores
things
on
a
flat
file
system,
whereas
wordpress
uses
a
database
such
as
mariahdb
and
part
of
the
dream
that
we're
also
going
after
here
is
regardless
of
how
these
two
applications
store
their
data
when
we
view
them
on
this
app
screen.
A
Both
of
them
are
going
to
have
the
same
sort
of
mechanism
for
doing
a
snapshot,
storing
the
metadata
around
how
that
app
is
deployed
on
kubernetes
what
those
settings
are
that
are
important
for
getting
that
snapshot
restored
and
up
and
running
all
of
that's
going
to
be
captured
in
this
action
when
we
click
this
snapshot
button.
So
I
can
click
snapshot
here.
I
can
also
configure
some
of
the
details
of
where
this
snapshot
is
stored
and
named
and
all
that
other
stuff.
A
So
this
is
ensuring
that
my
jenkins
production
cluster
is,
you,
know,
stored
and
backed
up,
and
I
can
easily
restore
it
and
one
example
of
how
you
might
want
to
use
this
in
the
real
world
is:
maybe
you
want
to
take
a
snapshot
of
jenkins
and
move
it
over
to
staging
to
mess
around
with
some
of
the
pipelines?
Maybe
you
want
to
look
at
some
of
the
errors
that
are
happening
on
jenkins.
You
want
to
do
something
potentially
destructive
to
the
service,
but
you
don't
want
to
test
that
on
production.
A
Well,
these
snapshots
and
this
the
way
we
are
storing
data
in
this
project
astra
system
makes
it
really
easy
to
tinker
with
those
sorts
of
things.
So,
if
I
switch
tabs
over
to
jenkins,
I
can
see
you
know
we
have
some
pipelines
defined
for
sort
of
a
mock
e-commerce
site.
Here
we
have
product
pages,
recommendations,
shopping,
cart,
there's
an
error
with
shopping
cart,
so
we
could
maybe
move
this
whole
system
over
and
start
tweaking
some
of
these
pipelines,
maybe
redefining
them.
A
So
all
we
have
to
do
to
create
a
copy
of
that
instance
that
we
want
to
either
name
staging
or
that
we
want
to
test
our
destructive
sort
of
actions
on.
We
just
have
to
click
this
clone
button
and
that
clone
all
that's
going
to
do
is
either
take
a
copy
of
the
live
state
as
it's
running
currently
in
production,
or
we
can
look
at
some
of
the
snapshots
that
we
have
recently
taken
as
well.
A
So
we
can
see
that
a
third
element
has
been
added
to
our
screen
here
and
if
we
were
to
click
into
our
new
staging
eu
west
we'd
find
that
this
is
its
own
sort
of
instance,
so
it
has
its
own
deployment.
If
we
look
at
some
of
the
data
that's
stored,
it
has
its
own
set
of
snapshots.
We
had
four
for
our
other
system,
so
this
is
brand
new.
This
is
great.
This
is
exactly
what
we
want.
We
can
take
a
destructive
action.
We
can
do
cool
stuff.
A
That'll
gives
us
a
lot
more
flexibility
in
how
we
run
our
applications
and
manage
our
infrastructure,
but
it's
also
consistent.
It's
the
same
sort
of
interface
for
any
application
that
we're
running.
So
you
may
notice
on
the
screen
that
we
have
a
europe
west
and
a
u.s
central
location.
How
do
we
get
compute
added
to
project
astra,
so
that
also
is
relatively
simple
and,
as
stated
previously,
we
hope
to
support
as
many
clouds
and
as
many
deployment
targets
as
possible,
so
from
your
private
cloud
to
all
the
major
clouds
out
there.
A
A
A
All
right-
and
it
was
that
easy
so
through
some
movie
magic
we
fast
forwarded,
and
we
can
see
that
we
now
indeed
have
a
new
ap
northeast
region
in
addition
to
our
other
clusters.
So
all
that
astra
is
doing
is
installing
trident
for
the
storage
layer
and
then
using
those
credentials
to
see
what's
running
on
the
kubernetes
cluster
and
bring
apps
under
management
that
we
want
that
backup
and
storage
capability
on
the
final
bit
that
we
should
probably
cover
is
just
that
astra.
A
While
we
have
this
nice
ui,
it's
built
with
a
mindset
of
automation
and
cloud
native
first,
so
we
also
provide
an
api
for
you
to
access
all
the
commands
that
you
could
get
at
through
the
ui
here,
programmatically
closing
out
things
we'd
like
to
just
discuss
the
roadmap
of
astra
with
you.
We
are
hoping,
as
mentioned,
to
support
as
many
clouds
and
on-premise
options
as
possible
and
as
part
of
that,
we're
looking
for
portability.
So
we
want
the
option
to
burst
workloads
to
the
cloud
for
taking
advantage
of
those
elastic
resources.
A
And
finally,
you
may
have
heard
that
you
know
netapp
acquired
spot
recently,
so
we
see
spot
as
a
cool
company.
That's
right
sizing
cloud
resources
for
any
app
under
the
sun,
any
infrastructure
under
the
sun,
and
we
think,
if
astra
can
grow
to
support
that
same
huge
variety
of
applications.
There's
some
really
cool
synergy
that
can
appear
between
project
astra's
aim
and
the
vision
for
spot
as
well.