►
Description
Containers are great for stateless applications and as the container technologies like Kubernetes mature containers are proving more and more beneficial for stateful applications. In this talk we will discuss data persistency in general in a containerised environment. We will take a deeper look at stateful applications and try to understand the challenges of deploying them in a containerised environments. We will see how we can leverage different Kubernetes features e.g. PersistentVolumes, Persi
A
Good
afternoon
everybody,
my
name
is
Kapil
Arora
I
work
at
NetApp,
and
today
we
are
going
to
talk
about
persistent
volumes
and
stateful
sets.
So
if
you
were
there
for
the
last
session,
there's
a
lot
of
overlap
between
the
two
sessions.
I
will
also
go
through
similar
concepts,
but
I
realized
that
when
I
was
looking
at
that
session,
I
was
also
you
know,
learning
some
stuff
from
that.
So
I
think
it
will
be
good
for
us
as
well
to
go
through
these
concepts
again.
A
So
what
do
I
have
it
on
my
agenda
today
we
are
going
to
talk
mostly
about
stateful
applications
and
I
will
try
to
explain
what
stateful
applications
really
are.
What
do
I
mean
by
stateful
applications?
Then
we
will
learn
about
the
concepts
in
kubernetes
around
storage,
so
we
will
go
through
the
concepts
of
volumes.
Persistent
volumes,
persistent
volume
claims
and
I
will
also
talk
about
stateful
sets,
which
was
not
part
of
the
last
presentation
and
which
is
very
new
to
many
kubernetes
users
as
well.
A
I
will
talk
about
NetApp
Trident,
which
is
our
integration
into
kubernetes
and
lastly,
I
belong.
I
also
have
a
couple
of
demos
to
show
you
guys.
So,
let's
get
started
so
when
we
talk
about
application
data,
if
we
divide
it
in
on
a
very,
very
high
level,
we
can
classify
them
as
structured
and
unstructured
kind
of
data.
So
if
I'm
talking
about
media
or
log
files
pictures,
they
are
mostly
unstructured.
Kind
of
data
and
I
can
put
these
data
into
object.
A
Storage
or
I
can
use
file,
shares
or
NAT
storage
for
these
kind
of
storage
right
and
then
you
have
application
data,
which
is
more
relational
kind
of
data,
which
is
transactional,
which
you
want
to
query
fill.
Maybe,
and
this
kind
of
data
is
usually
stored
in
your
databases
like
my
sequel
or
Postgres,
which
are
sequel,
databases
or
you
would
store
them
in
no
sequel,
databases
which
are
becoming
very,
very
popular
amongst
people
who
are
doing
cloud
native
kind
of
programming
because
you
can
scale
them
horizontally.
Of
course
right.
A
So
one
is
that
you
just
use
network
storage
or
your
host
based
storage
and
provide
storage
to
your
containers
where
they
can
store
their
persistence,
so
that
could
be
for
for
an
application
which
is
written
for
object,
storage
that
could
be
just
object,
storage
or
file
shares,
or
could
also
be
I,
scuzzy
LUN
or
any
any
kind
of
network
storage
that
you
are
you
know
familiar
with,
but
to
actually
store
this
data.
You
might
want
to
use
a
database
as
well
right
and
today
we
want
to
talk
about.
A
Does
it
really
make
sense
to
run
these
applications
within
a
database?
For
examples,
sorry
I
mean
to
say
it:
does
it
make
sense
to
run
such
applications
which
store
your
data
right?
These
data
stores,
like
my
sequel,
databases
or
sequel
databases,
or
no
sequel
database
and
key
value
stores
within
containers
right?
A
A
So
there
was
a
time
when
virtualization
came
into
the
picture,
and
people
thought
that
it's
not
a
good
idea
to
run
your
Oracle
databases
within
your
VMs
and
people
were
scared
to
do
that.
And
today
many
people
are
skeptical
about
running
databases
within
containers,
but
I'm
sure
that
the
technology
will
mature
enough
will
be
mature
soon
enough
for
us
to
be
able
to
actually
run
all
kinds
of
databases
within
containers.
So
what
advantages
do
I
get
out
of
doing
that?
A
So
one
of
the
major
advantages
that
I
see
especially
for
database,
is
that
scale
is
that
scaling
these
applications
become
really
really
easy
and
I
have
a
demonstration
with
MongoDB
in
which
we
will
actually
show
you
how
you
can
scale
MongoDB
with
stateful
sets.
So
that
is
one
of
the
very,
very
good
advantage
that
I
see
and
then,
when
you
are
working
in
these
environments,
you
know
that
you
can
write
a
yeah
mill.
A
You
can
write
a
gamble
for
your
whole
deployment
and
then
you
can
make
it
repeatable
and
also
standardize
how
you
deploy
your
applications.
So
that
is
another
advantage
that
you
get
out
of
container
izing
your
databases,
for
example,
and
then
handling
node
failures.
Handling
upgrades
could
be
made
much
more
simpler
by
providing
databases
within
containers.
So
these
are
some
of
the
advantages
that
I
believe
are
important
and
can
actually
help
in
all
kinds
of
environments,
and
that's
why
we
are
talking
about
it
today.
A
So
now
that
we
have
set
a
stage
for
what
we
mean
by
stateful
applications
and
what
we
are
going
to
talk
about.
Let's
get
into
the
concepts
within
kubernetes
so
to
provide
persistent
storage
within
kubernetes,
we
have
a
concept
called
volumes.
Kubernetes
volumes
and
kubernetes
understands
a
lot
of
different
kinds
of
storage.
So,
if
you
see,
on
your
left
hand
side,
you
have
our
DB
from
safe
ice
cozy,
NFS
EBS
from
Amazon
cinder,
Google,
Cloud,
Engine,
persistent
disks
and
ashur
as
well.
A
So
all
these
storage
is
understood
or
undone
kubernetes
understands
all
these
storage
types
and
all
these
storage
plugins
are
implemented
within
the
cubelet.
So
if
you
want
to
use
within
your
pod
or
your
application,
any
of
these
kinds
of
storage-
it
is
already
available
to
you
or
kubernetes,
already
already
understands
and
can
make
available
these
different
storage
to
your
application.
So
if
you
see
in
this
case,
if
I
want
NFS
to
be
available
to
my
pod,
I
can
just
provide
information
within
my
Amal
and
then
the
pod
can
actually
access
this
particular
volume.
A
Now.
What
we
just
looked
at
was
something
which
was
directly
connected
to
the
pod
right.
So
if
my
pod
dies,
my
volume
is
not
available
anymore
and
I'm.
Managing
my
volume
within
my
pod
right,
but
I
don't
want
to
do
that.
I
want
to
use
persistent
storage
as
a
cluster
resource
or
something
that
might
developers
can
use
right.
For
example,
I
have
compute
and
I
can
make
available
this
compute
to
my
users
of
the
cluster
right.
Similarly,
I
want
to
provide
storage
to
the
users
and
make
it
make
this
storage
available
to
them.
A
There
comes
to
new
concepts
that
we
will
talk
about,
and
first
is
persistent
volumes.
So
what
persistent
volumes
are?
They
are
network
storage?
Mostly,
they
can
be
local
storage
as
well,
but
today
we
are
talking
about
network
storage.
They
are
a
cluster
resource,
an
administrator
need
to
actually
provision
this
storage
and
make
available
within
his
cluster.
It
could
be
NFS,
I,
scuzzy
or
any
kind
of
cloud
storage
that
you
want
to
use,
and
it
is
independent
of
the
pod
lifecycle,
so
it
has
when
it
is
actually
provision.
A
It
has
nothing
to
do
with
the
pod
at
that
moment.
This
is
an
example
of
a
PV,
so
basically
I'm
just
providing
NFS
server
details
and
the
path
to
that
particular
volume.
That's
it
and
it
would
be
something
similar
for
I
scuzzy
that
we
saw
in
the
volume
we
need
to
provide
all
the
details
about
the
ice.
Cozy
connection
and
I
can
provide
a
persistent
volume
or
define
a
provision
of
persistent
volume
like
this
within
my
environment.
So
this
will
be
done
by
the
cluster
admin
now
to
consume
this
storage.
A
A
developer
needs
to
create
something
called
a
persistent
volume
claim.
So
he
needs
to
claim
the
storage
right
and
he
will
do
that
within.
He
will
do
that
and
then
use
that
claim
within
his
pod
right
and
he
will.
He
will
define
what
kind
of
storage
he
needs,
what
kind
of
access
mode
he
needs
for
that
particular
storage,
what
size
he
needs
and
what
is
the
reclaim
policy?
Basically
the
pod
dies
or
if
he
deletes
the
claim
what
happens
to
the
volume.
A
So
this
is
an
example
of
how
a
developer
will
use
persistent
volume
claims,
so
he
will
actually
define
a
persistent
volume
claim
about.
You
know
he
will
tell
the
access
mode.
He
will
tell
how
how
large
his
volume
should
be,
and
then
within
his
pod,
you
can
see
that
he
is
providing
details
about
the
volume
and
just
using
persistent
volume
claim
name
to
add
volume
to
his
pod
right
and
then
he
is
providing
the
volume
mount
location
and
then
he
can
use
this
persistent
volume
within
his
application.
A
So
what
we
just
saw
is
basically
static
provisioning.
The
administrator
will
actually
provision
this
storage
beforehand
and
then
the
developer
or
the
user
of
the
cluster
is
actually
going
to
consume
it.
But
it
is
also
possible
in
kubernetes
now
that
the
developer
is
creating
a
claim
and
the
storage
is
getting
provision
dynamically
for
the
user.
So
it's
more
self
service
oriented
right.
So
that
is
also
possible,
and
now
we
will
actually
discuss
these
two
possibilities
within
kubernetes.
A
So
here
you
can
see,
I
have
a
cluster
admin,
I
have
a
kubernetes
cluster
and
I,
have
a
user
or
a
developer
of
this
cluster
and
the
cluster
admin
has
access
to
a
store
system.
In
this
case
it
is
NetApp
SolidFire
and
of
course
the
user
doesn't
have
direct
access
to
the
store
system.
The
cluster
admin
provision
storage,
so
he
creates
persistent
volumes
TVs,
and
these
are
now
cluster
resources
available
for
a
developer
to
consume.
Right
and
now
the
developer
writes
two
pods
and
he
says
I
need
two
volumes
and
he
creates
persistent
volume
claims.
A
So
if
you
can
see
the
left,
one
is
for
five
GBS
and
it
the
right
one
is
atvs.
So
now
what
happens
as
soon
as
these
persistent
volume
claims
are
created,
the
PV
controller
from
kubernetes
takes
control
and
he
actually
does
the
mapping
of
of
the
claim
and
the
persistent
volume
that
exists.
So
in
this
first
case
you
can
see
the
5
GB
volume
was
mapped
to
the
5g
volume,
which
was
easy
for
the
controller,
but
the
other
case.
The
provision
storage
was
10
jeebies,
but
the
developer
only
asked
for
a
TVs.
A
So
there
is
a
slight
mismatch,
but
still
is
able
to
fulfill
is
request.
Just
imagine
if
the
other
storage
100
TB,
then
the
100
GB
volume
will
be
mapped.
So
there
is
some
because
there
is
a
manual
effort
required
there
is.
There
could
be
some
mismatches
in
this
case,
which
probably
we
don't
want
right.
So
this
is
static,
provisioning
in
kubernetes
and
how
a
cluster
admin
creates,
storage
and
a
user
consumes
storage.
A
Now
we
will
talk
about
dynamic
storage
provisioning.
So
what
is
that?
But
before
we
go
into
dynamic
storage,
provisioning
I
want
to
introduce
storage
classes.
It's
not
that
storage
classes
can
only
be
used
in
dynamic
provisioning,
but
it
is
important
to
learn
about
storage
classes
before
we
actually
learn
about
dynamic
provisioning.
So
storage
classes
is
a
way
for
the
cluster
admin
to
define
what
kinds
of
storage
he
has
available.
Does
he
have
SSDs
or
solder
disks?
A
Does
he
have
a
storage
system
which
can
provide
different
kinds
of
you
know:
quality
of
service
levels
like
SolidFire
or
does
he
have
separate
drives
which
are
encrypted,
so
he
has
different
kinds
of
storage.
Storage
classes
gives
him
an
opportunity
to
actually
find
a
storage
kind
of
a
catalog
for
his
users
to
consume
right,
so
it
could
be
QoS
levels,
it
could
be
gold,
silver
bronze.
It
could
be
their
staging
or
production.
So
that's
the
idea
of
storage
classes.
Now,
let's
also
look
at
a
couple
of
examples
for
that.
A
So
in
this
case
this
is
for
cinder,
so
I'm
providing
something
called
a
provisioner
which
we
will
discuss
about
in
a
bit
and
I'm
saying
which
availability
zone
should
it
be
which
type
of
storage
it
way.
So
this
is
an
example
of
a
cinder
fast,
no
availability
zone
storage
class.
Now,
if
we
talk
about
something
that
we
can
do
with
NetApp
I
can
define
okay,
this
storage
system
and
go
type
of
storage,
and
this
is
something
also
that
we
will
look
at
later.
A
But
basically
this
is
how
you
can
define
storage
classes,
and
this
is
the
the
whole
point
of
storage
classes
within
kubernetes.
Now,
let's
look
at
how
dynamic
storage
provisioning
works,
so
I
have
the
same
environment
that
I
had
before
I
have
a
developer.
I
have
a
kubernetes
cluster
and
I
have
my
clothes
treadmill,
but
in
this
case
I
have
more
storage
class
play.
What
what
the
cluster
admin
needs
to
do
now
is
basically
create
these
three
classes
or
whatever
classes
he
wants
to
do
and
deploy
a
provisioner.
A
So
in
this
case
we
are
deploying
the
trident
provision.
A
kubernetes
also
comes
with
its
own
provisioner,
which
which
supports
different
storage
types,
but
NetApp
has
written
its
own
provision,
which
we
are
going
to
showcase
today.
So,
in
this
case,
he
deploys
the
provisioner,
which
is
trident
and
he
defines
different
storage
classes
and
we
thought
it.
It
makes
sense
for
the
SolidFire
storage
system
to
define
it
in
terms
of
I
ops,
SolidFire
system,
which
can
give
you
guaranteed
AI
ops.
So
it
that's.
A
His
job
is
done,
and
now
the
developer
says:
I
need
for
my
application,
5
or
8
GB
of
gold
storage,
which
should
be
read/write
once
what
happens
in
this
case
is
Trident
is
looking
out
or
checking
what
kinds
of
PV
and
PVCs
or
storage
glasses
exist
in
this
environment,
and
it
finds
out
that
there
is
a
new
request
or
new
claim
that
has
been
created
for
storage
and
it
dynamically
provisions.
The
storage
talking
to
the
SolidFire
system
directly,
it
provisions
a
GB.
Actually,
this
is
wrong.
A
It
should
be
8gb
of
storage
for
the
user
and
once
he
does
that
this
mapping
is
again
done
in
a
similar
manner
as
previously
by
the
PV
controller
right.
So
what
is
the
difference
in
this
case?
In
this
case
the
developer
only
needed
to
know
the
storage
class
he
wants
and
the
size
he
wants
for
this
particular
storage
and
the
storage
was
dynamically
provisioned
for
him
and
he
didn't
need
to
wait
for
somebody
to
create
it
or
have
it
pre
provision
for
him.
A
So
that's
the
difference
and
that's
the
advantage
that
you
get
in
dynamic
provisioning.
So
there
are
lots
of
dynamic
provisioners
which
are
already
available
so
there's
trident
from
NetApp.
Then
you
have
OpenStack
cinder,
Amazon
EBS,
Google,
Cloud,
Engine,
persistent
disks,
cluster
FS
and
surface
RT
V.
These
are
the
ones
I'm
aware
of
which
you
can
already
use
with
the
kubernetes
provisioner,
which
is
available
by
default.
A
A
A
So
I
have
two
storage
classes
that
I
have
defined
here.
So
as
a
developer,
I
don't
need
to
know
much
more
than
what
storage
classes
I
have
available.
That's
all!
So
we
are
right
now,
acting
or
I'm
pretending
to
be
a
developer.
Who
wants
to
deploy
an
application?
So
let's
look
at
my
application,
so
I
have
a
wordpress
and
my
sequel,
application
that
that
I'm
going
to
show
so.
A
A
It
should
only
be
mounted
at
one
place
at
the
time
right,
so
it
shouldn't
be
like
an
NFS
store.
It's
basically
like
your
sand
storage,
so
I've
also
created
a
persistent
volume
claim
for
my
WordPress
disk,
which
should
be
also
of
the
go
type,
which
is
a
smaller
share,
that
I
need,
or
a
smaller
volume
I
need.
So
this
is
basically
a
wordpress
on
my
sequel.
Application
I
have
defined
services
from
my
my
sequel
to
expose
the
port
3306
so
that
my
WordPress
can
connect
to
it.
A
I
have
a
service
for
the
web
front-end
so
that
I
can
expose
it
to
the
outside
world,
and
now
this
is
my
my
sequel
pod
and
you
can
see
that
I
have
my
volume
here,
which
should
be
on
this
path
and
I'm,
using
my
persistent
volume
claim
that
I
created
earlier
to
provide
volume
to
my
pod
right
and
same
is
the
case
for
my
WordPress
found.
So
I
am
providing
my
claim
so
as
a
developer.
From
the
storage
point
of
view,
I
am
just
creating
a
persistent
volume
claim
and
nothing
more
than
that.
B
A
C
A
So
so
my
wordpress
application
is
deployed
and
let's
see
if
persistent
volumes
were
actually
created
for
my
application,
so
cube
CTA
get
P
V.
So
this
is
the
persistent
volume.
So
there
were
no
persistent
volumes
earlier
in
this
environment
and
as
soon
as
I
ran
this
Yammer
and
asked
for
persistent
volumes,
they
were
on
demand
created
by
Trident
for
my
developer,
so
the
developer
doesn't
need
to
understand
anything
about
storage.
C
A
A
It
was
clear
from
from
the
graphic
and
also
from
the
demo
as
to
how
a
developer
and
a
cluster
admin
will
work
together
and
how
they
will
use
storage
classes.
Persistent
volumes
or
persistent
volume
claims
to
actually
run
their
applications
right.
So
now
there
is
a
new
concept
that
I
want
to
introduce
you
to
you
that
is
called
stateful
sets
it's
a
very
new
concept
within
kubernetes
and
it
is
to
run
applications
which
have
different
kind
of
features,
and
let's
see
what
what
do
these
applications
need
to
have
for
me
to
consider
stateful
sets.
A
So
if
you
have
an
application,
for
example
like
MongoDB,
and
you
want
to
scale
it
horizontally,
what
you
need
to
do
is
whenever
you
create
a
new
instance
of
MongoDB,
you
need
new
storage
attached
to
it
and
if
you
are
running
a
regular
replica
set
or
deployment
whenever
you
scale
this
application,
a
regular
replica
set
or
or
a
deployment
within
kubernetes,
you
will
see
that
the
same
storage
gets
attached
or
gets
consumed
by
that
part
right.
So
that
doesn't
really
work
in
the
case
of
MongoDB.
A
Other
important
point
is
that
when
we
are
creating
a
MongoDB
replica
set,
the
nodes
need
to
talk
to
each
other
right
and
if
they
are
getting
scheduled
again
and
again,
their
network
identifies
will
change.
So
if
you
need
that
your
application
has
a
unique
network
identifier
and
is
able
to
talk
to
each
other,
for
example,
in
case
of
a
replica
set,
you
need
unique
identifiers
for
that.
So
that
is
something
that
stateful
sets
can
offer
us
and
then,
if
you
need
order
deployment
of
your
pods.
A
So
in
case,
if
I'm
deploying
three
replicas
or
three
instance
database
and
I
want
one
node
to
come
after
the
other
and
not
all
of
them
to
come
up.
At
the
same
time,
then
probably
I
would
want
to
use
something
like
a
state.
So
these
are
some
of
the
reasons
or
some
of
the
use
cases
for
applications
like
these.
You
would
use
stateful
sets.
A
So
how
do
you
define
a
stateful
set?
So
basically,
there
is
a
standard
definition.
How
you
do
that,
so
you
define
a
headless
service.
I
will
show
you
what
that
is.
Basically
you
don't
provide
any
cluster
IP
to
it.
So,
for
example,
if
it's
the
case
of
and
I
have
three
nodes,
I
can
access.
My
notes
by
saying
one,
if
my
is
my
headless
service,
for
example,
so
I'm
able
to
access
the
nodes
with
their
unique
with
their
new
identifier,
which
is
given
to
them.
A
As
you
know,
as
a
number
one,
two
three
then
the
other.
Of
course,
the
component
when
we
are
using
stateful
set
is
the
stateful
set,
where
I
can
define
what
pod
I
need
to
run
and
the
number
of
replicas,
for
example,
and
then
lastly,
I
need
to
provide
a
volume
claim
template.
So
in
this
case,
I
am
NOT.
Creating
volume
claims
myself
persistent
volume
claims,
but
I
am
providing
a
template
every
time,
I
create
a
new
node
for
this
particular
application.
A
A
A
This
is
one
EML
file,
but
I
have
divided
into
three
parts:
to
show
you,
the
three
sections
so
I
have
my
stateful
set
where
I'm
saying
the
replicas
should
be
three
then
I'm,
defining
which
image
to
use
which
docker
image,
for
example,
in
this
case,
what
container
port
it
exposes
and
which
path
the
volume
should
be
mounted
and
then
I'm
defining
a
volume
claim
template.
So
how
should
the
volumes
be
created?
Which
storage
class
should
be
used
and
then
finally
I'm
defining
the
headless
service?
A
A
A
I'm
also
defining
the
grace
period
for
termination.
If,
if
I'm,
starting
or
stopping
the
containers,
how
much
time
it
should
take
and
I'm
defining
the
command
for
my
MongoDB,
you
will
also
notice
that
I
have
one
more
sidecar
application
which
will
actually
take
care
of
creating
the
creating
the
replica
set
and
I'm
defining
where
I'm
going
to
mount.
This
particular
volume.
A
A
So
you
see
I
just
created
the
service
and
the
stateful
set.
Now,
let's
watch
how
these
MongoDB
instances
are
coming
up,
so
you
can
see
that
0
start
it
to
create
right
and
I
fast
forward.
With
this
you
can
see
the
timer
running
on
the
side.
So
once
one
goes,
0
is
running,
then
the
one
starts
to
come
up
right
and
then
once
one
comes
up
after
that,
2
will
start
to
come
up.
So
basically
it's
ordered
in
this
case.
A
A
So
now
now
is
a
very,
very
important
thing
that
stateful
sets
offer
us
now
if
I
want
to
scale
it
to
five
nodes.
What
do
I
do,
which
this
can
be
done
by
a
very
simple
application?
Just
imagine
how
would
you
scale
a
database
in
the
earlier
times,
but
here
I
can
just
say:
cube,
cube,
CDR
scale,
define
the
number
of
replicas
and
give
the
stateful
set
name,
and
that's
it,
and
now
my
MongoDB
application
will
have
five
replicas
five
five
nodes.
A
As
part
of
the
replica
set
and
which
will
also
come,
come
up
in
an
ordered
way,
so
that's
the
magic
that
stateful
sets
can
offer
you
for
applications
or
databases
which
can
scale
horizontally
for
databases
which
need
to
be
each
need
to
come
up
in
an
ordered
way
right.
So
one
part
that
I
still
would
like
to
show
is:
how
was
the?
How
was
the
provision
are
configured?
So
we
saw
that.
A
A
A
So
here,
I'm,
defining
or
as
a
cluster
admin
I
am
providing
details
about
how
to
connect
to
my
cluster
and
you
can
see
I'm
also
defining
the
different
classes,
so
I'm
saying
bronze
should
have
quality
of
service,
which
it
should
be
minimum,
this
much
maximum
that
much
inverse
triops
I'm,
defining
right
in
my
back
end
and
then
I'm
defining
a
storage
class
on
top
of
that
which
also
we
can
look
at
in
the
definition.
So
basically,
the
administrator
need
to
define
a
storage,
back-end
and
storage
classes.
So
let's
also
look
at
the
storage
class.
A
So
so,
basically,
the
backend
I
defined
I'm.
Choosing
that
back-end
and
saying
choose
the
gold
definition
that
I
have
put
in
my
back-end.
So
that's
it
right.
So
that's
how
that
was
the
administrator
part.
So
whatever
we
looked
at
before
was
how
the
developer
was
using
it
in
MongoDB
example,
and
also
in
the
WordPress
example,
and
now
what
I
showed
you
was
the
part
that
the
administrator
had
already
configured,
such
as
the
backend
and
the
storage
class.
A
So
the
MongoDB
example
that
I
showed
you
I've
written
a
blog
on
our
net
app
dot
IO
website.
If
you
are
interested
in
how
that
that
is
actually
run
with
trident,
if
you
are
interested
in
a
dev
storage,
you
can
actually
look
at
it
and
if
you
go
to
the
blog,
you
will
also
find
all
the
code
and
the
github
link
to
to
where
actually
the
code
repository
is
for
this
particular
example.
These
are
some
of
the
resources
that
you
can
use.
A
You
can
go
to
net
dot,
io
and
find
about,
or
also
we
have
a
slack
channel
where
you
can
discuss
about
how
we
implemented
our
provisioner,
for
example,
or
if
you
have
any
suggestions
on
how
how
it
is
working
today,
yeah,
that's
it
I
had
if
you
want
to
get
in
touch.
These
are
my
Twitter
Linkedin
and
github
IDs.
C
Hello,
the
question
is
so
we're
talking
about
persistent
storage,
persistent
items.
How
do
they
persist?
The
destruction
of
the
VM
or
destruction
of
the
whole
set
canopy's
elaborate
in
that.
How
do
we
reuse
the
data
right?
The?
How
do
we
save
what
was
in
the
database
after
we
destroy
the
whole
set
and
want
to
recreate,
maybe
with
a
newer
version
of
container
so.
A
So
what
we
looked
at
today,
like
the
MongoDB
example
I'm
using
a
network
storage
in
this
case
right,
so
what
stateful
sets
can
provide
us
is
those
unique
identifiers.
So,
even
if
my
pod
dies
and
is
rescheduled,
the
storage
is
network,
storage
and
cluster
has
access
to
the
storage,
so
the
the
the
pod
will
be
scheduled
on
a
different
node
or
even
the
same
node,
and
the
storage
will
be
made
aware
we'll
again
to
that
note.
A
So
that's
the
whole
point
of
having
stateful
sets
where
you
are
using
network
storage
and
you
can
still
handle
these
kinds
of
failures
or
node
failures.
So,
basically,
all
your
data
is
within
within
the
network
storage
and
you
are
created
for
the
scenario
when
actually
the
storage
as
a
way,
that's
why
you
are
creating
a
replica
set
so
that
the
storage
can
recover
and
provide
redundancy
there.
Thank.
A
C
A
Actually,
I
I
made
a
slide
on
that
as
well,
but
I
thought
it
would
be
too
much
detail.
So
basically,
there
are
three
types
of
reclaim
policies.
You
can
retain
your
data
if
you
like,
or
you
can
choose
to
delete
it.
So
if
a
persistent
volume
claim
is
deleted,
so
the
data
will
be
deleted
as
well.
You
can
choose
that
or
you
can
say,
I
want
to
retain
my
volume.
A
D
A
A
A
E
A
So
in
kubernetes
we
have
a
concept
of
namespaces
right,
so
you
can
set
quotas
number
of
volumes
that
a
consumer
can.
For
example,
you
can
say
this
particular
namespace,
which
is
for
one
developer
development
team.
This
particular
namespace
has
a
quota
of
one
terabyte
gold
storage
right.
So
you
can
do
something
like
that
and
once
the
storage
is
assigned
to
a
to
a
particular
pod,
then
it
is
available
to
that
board.
A
F
So
my
question
is
actually
around
like
local
attached
volumes,
so
I
run
a
lot
of
environments
and
some
of
them
very
small
and
we're
trying
to
keep
costs
down.
So
one
thing
that's
thrown
around
is
what,
if
we
could
just
use
the
storage,
that's
directly
attached
to
the
compute
nodes
themselves,
and
maybe
we
had
like
a
handful
of
compute
nodes
that
maybe
have
very
fast
storage
and
some
that
we're
just
kind
of
spinning
discs.
Are
there
any
options
and
kubernetes
to
kind
of
manage
that
type
of
situation?
F
A
I,
don't
know
if
you
were
there
before
my
session,
but
that
session
was
exactly
about
managing
local
storage
redo
this
session.
For
me,
so
basically
exactly
what
you
are
pointing
out.
There
are
applications
which
which
might
be
able
to
leverage
the
local
host
storage
and
which
could
actually
be
very,
very
fast
compared
to
or
it
could
use
it
as
a
cash.
You
know
cash
space
or
scratch
space
and
still
have
a
persistent,
some
level
of
persistence
available.
A
So
the
she
showed
how
you
can
use
persistent
volumes
and
persistent
volume
claims
exactly
what
I
showed
for
network
storage.
Now
you
can
use
that
for
PBS
and
PVCs
so,
and
somebody
asked
a
question
about:
can
you
use
actually
block
storage
from
the
host
which
she
said
that
people
are
working
on
that
and
if
you
are
interested,
you
can
come
to
the
cig,
kubernetes
storage,
sig
and
discuss
that.
So
there
is
work
going
on,
and
this
use
case
is
actually
a
use
case
that
that
is
coming
up,
and
we
had
a
talk
about
that.
B
A
F
A
So
the
question
is:
what
do
we
do
about?
Other
backends
and
I
showed
NetApp
as
an
example.
Basically
I
was
showing
you
a
provisioner
that
is
NetApp,
but
kubernetes
comes
with
the
tones
on
default
provisioner,
which
is
which
I
showed
as
kubernetes
dot
IO,
and
it
supports
different
storage
types.
So
dynamic
provision
should
already
work
for
Google
cloud
engine,
AWS,
EBS
cinder.
All
these
should
already
be
working,
but
I
have
not
tried
them
myself,
but
Trident
is
one
of
the
provisioners
and
kubernetes
comes
with
a
default
provisioner
and
supports
multiple
different
storage
types.