►
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
Kubernetes Storage 101 - Jan Šafránek, Red Hat & David Zhu, Google
Just getting started with Kubernetes?
In this introductory talk we’ll cover usage of persistent storage in Kubernetes so you can avoid its steep learning curve and common gotchas. Why does it look so complicated? What is a PersistentVolume? What is a PersistentVolumeClaim? Why are there two separate objects instead of just one? How is storage presented into my containers? How do I write scalable persistent applications? Where do I look to debug when storage is not working? How do I connect Kubernetes to my storage backend? What is this Container Storage Interface (CSI) thing that everybody is talking about??? We will answer all of these questions and more. You will leave this talk with a solid foundation for thinking about storage in Kubernetes as well as a greater understanding of how you can put the various pieces together to fit your unique use case.
https://sched.co/MPfk
A
All
right
we're
gonna,
go
ahead
and
get
started:
I'm
Tauron
I'm
from
Starr
I
work
on
open
policy
agent,
but
today
I'm
introducing
David
Zhu
from
Google
and
Yahoo
phrenic
from
Red
Hat
and
they're
gonna
talk
about
kubernetes
storage,
101
and
break
down
some
really
important
concepts
for
you
guys
so
go
ahead.
All.
B
Right,
hi,
everyone
thank
you
for
coming
to
our
storage,
101
talk,
so
let's
just
get
started
then
so,
first
of
all,
kubernetes
I'm
sure,
since
this
is
the
second
day
of
the
conference,
you
already
know
what
kubernetes
is.
But
basically
you
know
it's
like
a
container
Orchestrator,
but
we
like
to
think
of
it
as
a
pod
Orchestrator,
because
it
actually
works
on
pods
which
are
collections
of
containers
right
and
so,
as
we
may
know,
containers
are
generally
stateless.
They're
cleared
on
exit,
but
this
is
unless
persistent
storage
is
used.
B
So
that's
what
we're
gonna
be
talking
about
today.
So
here
is
an
example
of
a
pod,
and
this
is
actually
a
stateless
pod
right.
It's
just
got
a
my
sequel
image
and
notice
that
there's
no
like
storage
related
concepts
in
here
and
what
happens
is
that
this
pod,
actually
on
exit
the
entire
database
is
cleared
and
pods
actually
are
quite
ephemeral.
B
They
can,
you
know,
go
down
for
any
reason
and
they
can
go
down
because
of
preemption,
so
another
pod
with
a
higher
priority
comes
in
or
they
can
go
down
just
because
the
node
went
down.
So
this
my
sequel
database
is
not
going
to
be
very
resilient,
so
that's
why
we
introduced
some
storage
concepts
in
kubernetes,
so
we
have
these
three
main
objects
here.
On
this
slide,
the
pod
I
just
introduced
and
the
two
main
storage
objects
that
we're
going
to
be
talking
about.
B
One
is
the
persistent
volume
claim,
and
this
is
the
applications
request
for
storage,
so
the
user
will
put
this
on
the
system
to
request
for
storage
and
the
persistent
volume.
This
is
the
kind
of
the
admin
object
for
storage.
So
this
is
how
the
admin
will
create
a
pointer
to
actual
physical
storage,
and
it
will
contain
all
the
like
gory
details
of
our
Alang
storage
and
and
these
two
objects
kind
of
bind
together
and
don't
worry
we'll
talk
a
lot
more
about
these
in
the
future
in
detail.
B
I
just
wanted
to
introduce
them
right
now,
so
you
might
be
asking
okay.
So
if
I
want
storage,
I
just
want
a
volume
right,
I
just
want
a
disk
that
connects
to
my
container.
Why
do
I
need
two
objects?
Why
do
I
need
a
persistent
volume
claim
and
a
persistent
volume
well
by
separating
these
concerns
the
concerns
of
the
user
and
the
concerns
of
the
admin
on
the
other
side,
we're
able
to
get
both
application
portability
as
well
as
a
little
bit
more
security
right.
B
So
let
me
talk
a
little
bit
more
about
the
portability
side,
since
the
persistent
volume
claim
online
contains
very
basic
information
that
the
user
workload,
requests
of
storage.
So
we'll
talk
a
little
bit
more
about
what
is
inside
it
later,
but
it
only
contains
very
basic
requests.
You
can
make
these
types
of
requests
on
any
type
of
cluster
on
any
type
of
underlying
infrastructure
right
and
the
persistent
volumes
which
the
admins
create
that
are
not
portable.
These
ones
are
different
per
cluster
based
on
your
underlying
infrastructure.
B
When
you
create
these
Christa's
and
volumes,
they
contain
all
of
the
details
about
the
underlying
storage
like,
for
example,
if
you're
using
an
NFS
storage
underneath
this
would
contain
things
like
your
credentials
and
the
IP
address
with
where
to
find
this
NFS
and
the
security
concern
is
also.
You
don't
want
your
users
to
be
able
to
kind
of
create
these
persistent
volume
objects
that
reference
underlying
storage,
because,
generally
you
don't
want
users
to
be
able
to
just
point
to
whatever
underlying
storage
they
want
to
write
in
the
case
of
NFS.
B
You
don't
want
them
to
just
put
some
random
IP
address
and
find
whatever
okay,
a
third
object
that
we'll
be
talking
about
today
is
this
storage
Clause
object.
John
will
be
going
into
more
detail
about
this
later.
But
basically,
what
you
need
to
know
now
is
that
this
is
for
dynamic
provisioning,
it's
a
collection
of
persistent
volumes,
so
if
we
take
a
bunch
of
persistent
volumes,
grouped
them
kind
of
by
class,
this
goes
all
under
one
storage
class
type
object
and
we'll
also
use
this
to
provision
things
dynamically.
B
So
we
can
see
here
that
in
this
container
we
have
some
volume
mounts
and
we've
specified
the
data
volume
and
we
want
it
to
go
into
this
path
into
the
into
the
container.
Okay
and
we've
also
defined
in
the
same
yeah
mol
file.
Actually
the
what
this
volume
is,
and
we've
just
defined
this
volume
as
a
pointer
to
the
persistent
volume
claim
that
were
that
we're
gonna
reference.
Okay.
So
what
does
this
persistent
volume
claim
that
we're
referencing?
B
Look
like
here's,
the
name
that
we're
referencing
and,
as
I
told
you
before,
it's
actually
very
simple
right.
It
actually
only
contains
the
most
basic
information
that
we
need
for
our
storage.
So
we
we
only
care
about,
you
know
we
don't
care
how
our
storage
is
given
to
us
or
what
underlying
volume
we
have
as
a
as
a
person.
Putting
this
workload
on
to
the
mate
on
to
the
cluster,
all
I
really
care
about
is
the
size
things
like
what
type
of
file
system
or
whether
I
want
block
or
the
access
mode
right.
B
B
So
in
order
to
create
this
claim
on
the
cluster,
you
just
do
a
cube,
total
create
F,
which
is
for
the
file,
and
we
have
the
claimed
animal
that
we
just
showed
earlier
and
we
can
also
get
the
PVC,
and
this
gives
us
some
more
information
about
the
PVC
on
our
system.
Okay,
we
can
also
create
our
pod
and
we'll
see
that
since
the
PVC
has
been
created,
it
has
something
to
reference
and
the
pod
will
start
running.
B
Okay,
a
quick
debugging
thing
for
PVCs,
if
you
just
get
the
PVC,
sometimes
you'll
note
that
it's
pending
and
you
won't
know
why
it
doesn't
note
how
this
doesn't
actually
say
anything
about
why
the
plot
of
the
PVC
is
pending,
really
important
to
know.
Describe
your
PVCs,
okay
describe
all
of
your
API
objects.
When
something
goes
wrong,
you
should
think
cube.
Control
described
okay.
So
when
we
describe
this,
we
get
some
events
at
the
very
bottom,
and
this
actually
lets
us
get
into
kind
of
what
the
actual
issue
is
here.
B
C
Participant
volume
is
the
first
object
that
is
for
administrators
to
play
administrator.
In
this
talk,
the
persistent
volume
is
just
bunch
of
better
metadata
and
pointer
to
the
rear
storage
compartment.
If
supports
I,
think
15
different
volume
backends
right
now,
all
of
them
are
hard-coded
in
kubernetes.
So
if
you
want
to
introduce
new
back-end,
you
need
to
go
to
kubernetes
code
and
write
it
there
and
the
kind
of
declared
stop
on
new
volume
plugins
and
instead
we
provide
two
extension
mechanisms:
how
to
connect
kubernetes
to
a
different
storage.
Back-End,
that's
not
listed
here.
C
We
provide
old
flex
and
new
fancy
CSI
container
storage
interface,
so
you
can
connect
kubernetes
to
a
storage
back-end
that
kubernetes
doesn't
know
anything
about
it.
If
you
look
at
the
details
about
the
metadata,
kubernetes
needs
to
know
the
capacity
of
the
volume
how
the
volume
can
be
accessed
and
to
which
storage
class
it
belongs.
So
this
is
some
cheap
storage
on
my
old
NFS
server
running
somewhere
in
my
infrastructure,
so
I
created
a
stretch,
class
called
cheap
and
the
last
bit.
C
C
So
this
person
volume
is
just
pointer
to
some
storage,
perhaps
outside
of
kubernetes
and
the
last
bit
that
or
so
created
by
Christ,
our
main
storage
class.
It's
basically
a
collection
of
persistent
volumes
that
share
some
common
characteristics
like
speed,
so
I
can
add,
fast
storage
class
and
slow
storage,
class
or
price,
so
I
can
have
expensive
storage
class
and
cheap
storage
class
or
I
don't
know,
replication
characteristics
or
I
can
have
safe
storage
class,
with
free
replicas
of
data
or
unsafe
storage
class,
with
just
one
replicas
of
the
data.
C
It
also
contains
parameters
for
dynamic
provisioning
that
is
used
when
kubernetes,
when
there
is
no
available
persistent
volume,
but
kubernetes
needs
Sam.
So
it
reaches
some
storage
back-end
and
provisions
the
data,
the
world
data
volume
automatically.
It
needs
to
know
whom
it
should
talk
to
it's
the
provisional
parameter
and
you
can
find
the
exact
values
you
can
put
here
in
either
in
kubernetes
documentation
or
in
documentation
of
storage
back-end.
C
If
you
use
CSI
or
an
external
provisioning
support,
and
the
provisionary
usually
needs
some
parameters
that
will
provision
a
persistent
volume
of
this
given
class,
so
this
class
is
called
fast
and
these
parameters
will
provision
the
fastest
volume
is
available
on
AWS.
The
parameters
are
different
for
each
storage
back-end.
That
means
this
object
is
not
very
portable.
If
I
take
this,
this
run
from
Amazon
I
can't
take
it
on
GC.
It
will
not
run
there.
C
I
will
need
to
provide
different
provision,
error
and
different
parameters,
and
each
cluster
I
strongly
recommend
should
have
one
default
storage
class.
The
four
storage
class
is
a
class
with
this
magic
notation
and
what
happens
is
when
user.
Like
david,
creates
person
volume
claim
without
referencing
any
specific
storage
class,
he
will
get
the
default
one.
So
in
this
case,
if
david
creates
a
claim
without
any
storage
class,
you
will
get
the
first
one.
C
The
persistent
volume
can
be
created
in
two
ways:
the
first
one
is
dynamic
provisioning
at
it.
You
should
use
that
in
your
clusters,
where
administrator
just
just
creates
a
storage
class
and
when
user
creates
a
persistent
volume,
it
either
references,
concrete
sludge,
class
or
no
storage
class
and
gets
the
default.
One
and
kubernetes
then
goes
and
creates
a
volume
on
the
storage
back-end
and
a
persistent
volume
object
in
kubernetes,
pointing
to
it
kubernetes.
C
C
The
other
option
we
support
is
manu
provisioning,
where
I,
as
administrator,
can
create
a
persistent
volume.
Object
in
Burnet
is
pointing
to
some
storage
outside
of
kubernetes
for
some
legacy,
data
that
are
pre-populated
and
I
want
to
use
them
in
kubernetes
and
user,
creates
exactly
the
same.
Persistent
wouldn't
claim
like
before
referencing
some
storage
class
and
kubernetes
will
find
the
existing
volume
and
bind
it
to.
The
claim.
C
Important
note
here
is
that
kubernetes
always
looks
for
existing
volumes
first
and
if
there
is
no
existing
volume,
that
would
match
the
claim
only
after
that
it
goes
and
dynamically
provisions
the
that
means
if
I,
if
this
is
some
pre-populated
data,
some
voting
with
repopulated
data
I
should
probably
create
a
special
storage
class,
so
somebody
accidentally
doesn't
create
a
persistent
volume
claim
requesting
basically
empty
volume
and
accidentally
binds
to
the
volume
with
the
data.
So
this
is
really
for.
C
Like
brown,
few
scenarios,
where
you
want
to
use
some
old
data
in
kubernetes,
you
should
use
dynamic
provisioning.
For
the
rest,
your
life
will
be
much
easier
and
when
user
can
create
support,
you
second
delete
a
pot
or
something
can
delete
the
pot.
The
data
are
still
retained.
User
can
create
as
many
pots
as
you
want
and
still
use
the
data.
That's
fine
and
when
user
doesn't
need
the
data
he
deletes
the
persistent
volume
claim.
C
That's
the
signal
to
compare
Nettie's
I,
don't
need
the
data,
do
something
about
that
and
what
happens
is
encoded
in
persistent
volume
reclaiming
policy
field
in
the
persistent
volume
I
showed
you
before.
We
support
three
policies.
We
support,
recycle.
We
support
it
only
on
an
NFS.
A
kubernetes
basically
deletes
all
the
data
from
the
volume
and
put
it
back
to
available
state.
So
it's
available
to
a
different
claim,
it's
kind
of
clunky.
It
doesn't
work
well
with
different
NFS
servers
and
so
on.
So
it's
deprecated.
C
It
may
work
for
you
but
accept
trouble,
expect
troubles.
The
more
useful
policy
is
delete
when
kubernetes
just
goes
to
the
storage.
Back-End
deletes
the
volume
there
deletes.
The
persistent
volume
object
in
kubernetes
and
the
volume
is
deleted
or
you
can
use
policy
retain
we're.
Just
kubernetes
puts
the
persistent
volume
aside.
C
Nobody
can
bind
to
it
because
there
can
be
I,
don't
know
qualified
numbers
on
on
the
volume,
but
the
data
is
still
there
and
is
faster
administrator
can
reach
the
data
or
bind
it
manually
to
a
different
persistent
volume
claim
if
David
comes
ask
nicely.
I
can
give
him
the
data
in
all
these
three
cases.
C
The
data
are
lost
for
the
user,
so
the
user
can't
access
the
data
it
either
can
go
to
me
and
ask
nicely
or
the
data
are
deleted,
so
be
very
careful
and
DirecTV
sees
you
will
lose
your
data
and
finally,
highest
administrator
can
delete
persistent
volumes
manually.
It
could
be
useful
in
some
cases,
but
again
be
very
careful.
You
are
dealing
with
some
data.
C
B
Right
so
we've
learned
about
the
pod,
the
PVC
and
the
PV,
but
actually
we
don't
recommend
using
pods
in
production,
environments
and
that's
kind
of
because
pods
are
not
really
for
end-user
production
right.
There
kind
of
ephemeral,
I've
kind
of
I
alluded
to
this
earlier
right.
They
can
be
kicked
off
for
many
different
reasons
and
when
your
pod
gets
kicked
off
of
your
machine,
you
actually
don't
have
access
to
your
workload
or
your
data
anymore.
So
if
you're
running
the
service
on
that
pod,
you
can
no
longer
hit
it
when
your
pot
is
gone.
B
So
how
do
we
fix
that?
Well,
we
have
some
higher
level
objects
in
kubernetes
that
can
help
you
with
your
with
your
issues.
Here
we
have
the
deployment
which
basically
just
runs
many
replicas
of
your
pod
template,
so
you
give
it
a
pod
and
it
just
Eck's
many
of
them
right
and
when
your
pod
gets
deleted.
For
any
reason,
like
your
someone
comes
in
and
preempts
your
pod
from
from
a
node,
the
deployment
will
actually
go
and
recreate
that
pod
for
you.
B
So
if
you
want
three
replicas,
you're
kind
of
always
going
to
get
three
replicas
eventually
we
can
scale
this
up
and
down.
We
can
have
more
less,
but
one
of
the
big
caveats
with
the
deployment
for
storage,
especially,
is
that
all
of
the
pods
in
your
deployment
share
the
same
persistent
volume
claim.
So
this
is
kind
of
what
it
ends
up.
B
Looking
like
you
have
your
deployment,
which
spawns
multiple
pods,
but
they
all
reference
the
same
persistent
volume
claim
and,
as
we
know
from
the
previous
slides,
that
means
that
it
will
reference
one
persistent
volume,
which
means
we'll
get
one
underlying
storage
right,
and
you
might
already
have
some
clue
as
to
why
this
might
be
a
problem
right.
So
all
three
of
these
pods
are
writing
to
the
same
volume,
writing
and
reading
from
the
same
volume.
B
B
There
are
a
lot
of
cases
where,
if
your
volume
is
read
right
once
your
pods
will
not
actually
come
up
on
a
second
note
or
a
third
node,
because
you
know
you
can
only
attach
them
to
one
node,
so
you
could
have
a
lot
of
issues
with
a
deployment
like
this,
while
using
staple
volumes.
But
you
know
there
is
probably
a
case
where
you
do
want
this,
and
you
have
to
be
aware
that
this
is
exactly
what's
happening
right.
B
B
You
can
scale
it
up
and
down
when
the
pod
dies
you
can
put
a
new
one
in,
but
the
very
the
main
difference
here
for
store
specifically,
is
that
each
pod
will
now
get
its
own
persistent
volume,
clamp
and
the
way
we
do
that
is
in
the
object.
You
actually
specify
a
persistent
volume
claim
template
and
that
templates
out
the
PVC
and
each
pod
will
get
like
kind
of
a
stamp
out
of
that
template
right.
So
this
is
kind
of
what
it
ends
up.
B
Looking
like
in
a
three
pod
case,
we
have
three
pods
here
and
three
PVCs
each
one
connected
to
a
pod
right.
So
in
this
case
each
pod
gets
its
own
volume,
and
this
is
generally
more
like
a
good
starting
place
for
what
you
want
right,
but
unfortunately,
kubernetes
doesn't
really
handle
your
application
needs.
B
But
kubernetes
does
not
do
this
application
specific
synchronization
between
your
pots
right,
so
you
can
use
a
stateful
set
as
a
building
block
for
your
workloads,
but
in
the
end
you
still
need
to
kind
of
determine
how
these
pods
interact
with
each
other
and
who
gets
to
serve
data
who
gets
to
write
data.
This
all
needs
to
be
determined
by
the
application.
C
In
kubernetes
to
be
accumulated
a
lot
of
features,
this
is
not
a
complete
list.
I'm
going
to
present.
This
is
just
very
high-level
overview.
What
you
can
use
and
you
can
mix
and
match
all
the
features
together
and
build
your
stateful
applications.
So
the
first
feature
is
topology
topology
over-scheduling.
C
Until
now,
we
sort
of
expected
that
if
you
have
persistent
volume
object
in
kubernetes,
we
expected
that
the
volume
is
available
to
all
nodes
in
the
cluster.
If
you
ran
a
cluster
across
multiple
availability
zones
in
cloud,
that's
usually
not
the
case.
A
persistent
volume
is
then
available
only
to
subset
of
nodes.
C
Kubernetes
can
know
about
that,
using
topology
over
scheduling
and
schedule
pots
to
note
where
the
data
is
accessible
and
we
also
introduced
something.
We
called
delayed
provisioning
where,
if
we
create
a,
if
user
creates
a
persistent
volume
claim,
it's
not
provisioned
immediately
because
it
could
be
provisioned
in
a
wrong
zone.
But
we
wait
until
a
pot
until
user
creates
a
pot
and
then
scheduler
looks
at
the
pot
requirements
like
it
means
a
GPU.
It
needs
eight
cores,
it
means
five
megabytes
of
memory
and
the
claim
it
needs.
C
Like
I,
don't
know
ten
gigabytes
of
storage
and
schedules,
both
the
pot
and
the
person
were
inclined
to
the
node
to
a
node
that
has
enough
storage
and
has
enough
CPU
power
and
GPUs.
So
in
reality
you
can
find
you
can
create
a
person
Emporium
claim
and
find
out
that
this
pending
and
the
reason
for
pending
is
that
it
is
waiting
for
the
first
consumer
and
after
you
create
a
pot
that
uses
the
frame
or
you
create
a
set
of
a
set,
of
course,
not
a
pot.
C
Only
after
that,
the
claim
is
by
gets
bound.
So
don't
panic
if
your
claims
your
are
pending.
This
may
be
the
default
mode
in
your
posture,
especially
if
you
run
across
multiple
availability
zones.
There
is
a
talk
today
later
today.
Michelle
is
covering
it
in
a
bit
other
feature.
We
have
local
volumes.
If
you
have
some
spare
hard
drive
or
SSDs
attached
to
your
nodes,
you
can
use
them
as
persistent
volumes.
C
C
Until
now,
if
you
use
the
volume
in
a
pot,
it
kubernetes
created
a
file
system
on
it
and
mount
it
in
inside
the
pot.
There
are
some
workloads
that
don't
like
it,
they
won't
extra
speed
or
they
want
to
handle
the
block
device
by
themselves.
So
now
you
can
use
robot
devices
and
you
can
get
a
road
block
device
inside
your
pot
and
you
can
do
whatever
we
want
with
it.
Kubernetes
won't
touch
any
data
on
the
volume
you
can
also
resize
your
volumes.
If
we
support
only
expansion,
you
can
increase
the
size.
C
You
can't
shrink
it
currently.
What
we
have
as
better
feature
is
of
fine
resize.
That
means
that
kubernetes
resize
the
volumes,
but
you
must
stop
your
pod
first.
So
if
you
have
a
stateful
set,
you
scale
it
down.
Besides
your
volumes
scale
it
up
and
new
pods
will
have
bigger
volumes.
We
are
working
on
online
resize.
That
means
that
you
won't
need
to
resize
to
stop
the
volumes
at
all.
We
have
it
as
alpha.
You
can
try
it
and
see.
Bug
fix,
bugs
and
bug
fixes.
C
In
line
volumes
initially,
it
was
not
on
flood
on
the
slides,
because
it's
damn
dangerous
but
you'd
need
to
use
persistent
volume
claims
and
persistent
volumes
at
all.
You
can
reference
a
volume
directly
in
a
port.
We
call
them
in
line
volumes,
they
are
in
line
in
the
pot,
so
this
port
runs
test
container
and
the
test
container
gets
mounted
this
Amazon
volume.
This
makes
the
pot
completely
not
portable.
C
You
can't
take
the
pot
and
run
it
somewhere
else,
because
the
volume
is
not
there,
but
maybe
that's
what
you
want.
You
need
to
just
test
something
or
run
a
job.
It
is
usable
what
more
usable
for
inline
volumes
are
ephemeral
volumes
you
already.
Maybe
you
already
met
them
in
kubernetes
we
used
config
maps
and
secrets
and
Denver
API,
where
you
can
get
a
configuration
or
some
secrets,
user
names
and
passwords
or
SSH
keys
as
files
inside
your
pods.
You
can
create
API
object,
called
concept
map
or
secret
with
which
are
basically
key
value.
C
B
We
also
have
some
new
features
to
talk
about
some
of
those
that
Yann
talked
about
when
you
as
well,
but
we
have
the
container
storage
interface,
which
is
an
industry
standard,
that
kind
of
enables
storage
vendors,
to
write
a
storage
plug-in
once
and
deploy
it
anywhere.
So
a
lot
of
different
container
orchestrators
have
implemented
the
container
storage
interface
and
they're
all
going
to
interface
with
the
same
drivers,
so
kubernetes
as
well.
We've
implemented
support
for
CSI
and
we
have
a
growing
number
of
drivers
in
the
ecosystem.
I
believe
it's
over
30.
B
B
Another
feature
that
we're
actively
working
on
that
is
currently
alpha
is
volume
snapshots.
So
this
is
a
part
of
the
container
storage
interface.
Basically,
it
lets
you
take
a
snapshot
of
a
PVC
at
a
point
in
time
and
we
get
the
snapshot
and
then
we
can
then
provision
a
new
volume
based
on
that
snapshot
and
and
use
it
later
in
a
different
pod
or
the
same
pod
or
something
okay.
We
have
one
final
feature
to
talk
about,
which
is
CSI
migration.
B
This
is
still
also
in
alpha,
but
this
is
a
push
to
kind
of
deprecated
sort
of
the
entry
plugins.
The
API
is
going
to
stay
if
you're
using
entry
plugins
today,
I
want
to
make
it
very
clear
that
you
can
still
continue
to
use
those
in
the
future,
but
what
we're
doing
is
actually
removing
all
the
backend
implementation
and
shimming
that
to
the
CSI
driver.
B
So,
as
I
mentioned,
the
container
storage
interface
before
30
plus
drivers,
more
frequent
updates,
better
security
guarantees,
we're
shimming
the
back
end
to
that,
so
you
can
still
use
the
same
entry
plug-in
interface.
Okay.
So
to
summarize,
the
main
takeaway
that
you
should
have
from
this
talk
is
this
image
right.
There
are.
There
are
two
main
parts
of
the
storage
system
in
kubernetes
right.
B
We
split
it
out
into
a
Schrader's
and
into
user
workload,
and
we
have
the
persistent
volume
claim
for
the
user
request
and
we
have
the
persistent
volume
for
the
administrator
for
all
of
the
gory
details
of
your
underlying
storage.
Okay
and
also
we
have
the
storage
class,
which
kind
of
groups
persistent
volumes
together,
and
we
can
use
that
for
dynamic
provisioning.
These
are
the
main
concepts
we
also
have
those
higher-level
workloads
deployments,
staple
sets
and
all
of
those
features
you
can
look
up
documentation
for
online.
B
So
that's
not
all
we
want
to.
If
you're
interested
in
storage,
we
have
a
ton
of
talks
about
storage
in
at
cube.
Con
about
half
of
these
actually
have
already
finished,
but
I
want
to
call
out
if
you're
interested
in
contributing
or
interested
in
more
about
what
we're
working
on
currently
I
would
recommend
coming
to
the
intro
deep
dive
for
the
kubernetes
storage,
sig
and,
of
course,
if
you're
interested
in
any
of
these
other
specific
storage,
related,
tutorials
or
talks,
you
know
take
a
picture
of
this.
B
Look
it
up
and
you'll
find
it
on
the
schedule
you
can
reach
out
we're
the
kubernetes
Storage
sig.
We
have
bi-weekly
meetings,
we
run
slack
and
we
have
a
mailing
list.
So
this
these
slides
are
online
on
the
schedule
you
can
download
them
and
click
on
these
links.
Thank
you
so
much
for
coming
and
thank
you
for
listening.
B
C
B
B
If
I
could
try
to
rephrase,
were
you
asking
if
a
pod
writes
to
a
local
volume
and
then
we
copy
that
data
to
a
cloud
volume
then?
Can
we
then
mount
that
cloud
volume
into
a
different
plot
or
back
into
the
same
pod
in
any
pod,
okay,
yeah?
So
so
I
think
we
can
just
break
this
down
into
two
separate
steps
right.
B
The
pod
writes
to
the
local
volume
you
just
use
all
of
the
kubernetes
concepts
we've
covered
to
mount
that
and
use
your
local
volume
copying
the
data
to
the
cloud
I
think
that's
a
separate
operation
that
you
would
do
outside
of
kubernetes
kind
of
right
and
then
mounting
that
cloud
volume
to
a
pod
again
is
just
using
the
same
basic
concepts
to
just
create
the
pv
for
that
cloud.
Volume
create
a
PPC
that
then
references
it
and
then
consume
that
by
your
pot.
Does
that
answer
all
right?
Any
other
questions.
F
Hi
I
would
like
to
ask
so
we
have
a
particular
situation.
We
have
an
NFS
storage
that
we
want
to
present
to
a
governess
cluster,
but
it
has
its
very
particular.
Every
directory
needs
to
be
accessed
only
by
specific
namespaces.
So
basically,
we
want
a
namespace
to
be
able
to
mount
one
and
only
one
directory
within
this
storage.
So,
as
far
as
they
know,
persistent
volumes
cannot
be
bound
to
namespaces
and
we
cannot
create
a
storage
class
because
for
host
path.
F
It's
not
supported
so
for
now,
the
only
way
we
can
control
this
is
using
port
security
policies
and
preventing
the
prefix
of
the
path
to
each
user.
That
is
connected
to
each
namespace.
But
this
is
a
very
complex
solution
for
a
very
kind
of
simple
problem.
So
is
there
an
alternative
way
to
make
sure
that
a
particular
persistent
volume
is
mounted
only
by
a
specific
namespace?
F
C
Is
no
easy
solutions,
there
is
no
easy
solution.
Resistant
volumes
are
sort
of
global
for
everybody.
We
don't
restrict
them
by
namespace,
but
what
we
do
restrict
our
storage
classes.
So
maybe
we
didn't
say
it
during
the
talk,
but
you
can
restrict
a
storage
class
with
quota
and
give
access
to
a
storage
class
only
to
one
namespace,
that's
possible.
But
then,
in
your
case
you
need
to
create
a
namespace,
a
class
for
each
namespace.
I,
don't
know
how
many
namespaces
are
you
going
to
have
if
it
is
view
that
it's
probably
feasible?