►
From YouTube: Tutorial: Introduction to Using the Container Storage Interface (CSI) Primitives - Michael Mattsson
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Tutorial: Introduction to Using the Container Storage Interface (CSI) Primitives - Michael Mattsson, HPE
The Container Storage Interface (CSI) does not only allow dynamic provisioning of Persistent Volumes from various vendors. It’s a wealth of new API objects that can perform various data management tasks through kubectl. In this end user focused session we’ll inform ourselves of the current status of CSI capabilities and demonstrate a few pragmatic use case of each individual feature. Learn about inline ephemeral volumes, volume expansion, raw block volumes and volume snapshot classes that will allow cloning and restoring of volumes — all with practical examples that can be broadly applied to many of the backend CSI drivers available. We’ll also discuss the anatomy of the already present primitives, Storage Class, Persistent Volume Claim and Persistent Volume for completeness.
https://sched.co/ekFc
A
A
My
name
is
michael
matson,
I'm
a
tech,
marketing
engineer
and
master
technologist
with
the
hula
packet
enterprise,
I'm
presenting
this
at
cubecon
virtual
2020
and,
if
you're
watching
this
live.
Thank
you
so
much
for
hanging
in
there.
This
is
on
the
last
day
and,
if
you're
watching
this
as
a
rerun.
Thank
you
so
much
for
for
watching
this
content.
I
hope
you
find
it
interesting,
so
this
tutorial
is
basically
all
about
csi
and
what
you
can
do
with
it
in
kubernetes,
and
that
is
sort
of
the
introduction
to
csi.
A
I'm
going
to
talk
about
some
of
the
csi
drivers
that
are
out
there
and
what
csi
is
the
the
second
part
of
the
presentation.
We'll
talk
a
little
bit
about
dynamic
provisioning
of
persistent
volumes
in
kubernetes
it.
I
think
it's
important
that
we
kind
of
nail
down
the
basics
before
we
go
into
the
more
advanced
topics,
and
I
also
want
to
talk
a
little
bit
about
how
parts
and
controllers
attach
to
persistent
storage,
as
that
is
also
a
very
important
primitive
to
understand.
A
At
the
end
of
the
at
the
end
of
the
presentation,
I
will
kind
of
summarize
what
we
talked
about
and
there
will
also
be
a
live
q
a
right.
So
this
session
is
pre-recorded,
but
at
the
end
of
the
session
there
will
be
a
live
q.
A
I
will
be
there
in
person
answer
any
questions
you
might
have
on
this
presentation
or
or
anything
that
kind
of
relates
to
this
subject.
A
A
It's
sort
of
like
the
cinder
for
kubernetes
right
with
the
benefit
of
that
the
drivers
and
the
entire
frameworks
live
outside
the
the
main
kubernetes
project
right,
so
the
drivers
and
and
all
the
side
cars
I'm
going
to
talk
a
little
bit
about
this
later.
They
they
know
they're,
not
part
of
the
main
kubernetes
upstream
tree
right,
so
that
their
the
sidecar
lives
in
their
own
repos.
All
the
csi
drivers
are
delivered
by
vendors
in
in
various
different
ways
right.
A
That
is
often
referred
to
as
a
ceo
right
and
we're
obviously
going
to
talk
about
kubernetes
today,
but
you
can
also
use
csi
for
nomad
or
cloud
foundry
and
mesos
and
and
those
are
like
the
the
less
popular
ones.
I
know
that
no
matter
has
got
csi
support
in
in
in
that
container
orchestrator
as
well.
So
we'll
probably
see
a
few
more
use
cases
for
that
coming
up.
A
A
What
came
along
in
kubernetes
1.2
is
the
entry
flex
volume
plug-in
and,
and
that
introduced
the
concept
of
allowing
vendors
to
to
write
flex
volume,
drivers
and
flex
volume.
Drivers
were
kind
of
useful.
It
was.
It
was
a
pretty
decent.
Stop
gap
but
somehow
that
become
became
very
unuser
friendly
as
well
right,
because
the
flex
volume
driver
itself.
It
was
it's
a
self-contained
binary
that
needs
to
be
needed
to
reside
on
every
cubelet
in
the
cluster.
That
was
supposed
to
attach
persistent
storage
and
it
did
not
have
any
dynamic
provisioning
support
either.
A
So,
if
you
had
a,
if
you
were
a
vendor
and
want
to
provide
a
flex
volume
driver,
you
also
have
to
write
your
own
provisioner
to
be
able
to
satisfy
persistent
volume
claims
with
that
driver
and,
and
that's
what
kind
of
when
we
can't
move
into
the
face
of
the
container
storage
interface.
It's
just
completely
lives
outside
of
kubernetes.
There's
like
nothing
inside
kubernetes.
That
depends
on
the
csi,
the
delivery
vehicles
of
csi
or
the
velocity
of
how
things
are
introduced
and
such
right
and
the
entire
framework
is
actually
deployed
on
top
of
kubernetes
right.
A
So
I
also
have
this
simplified
architecture
view
of
csi
right,
so
you
kind
of
have
the
the
side
cars
that
I've
been
talking
about.
First,
you
have
the
no
driver,
registrar
and
you
will
see
like
on
every
node
that
have
csi
drivers
on
them.
You
will
see
what
drivers
they
have
and
some
of
the
features
that
they
provide,
like
topology
keys
and
such
and
and
then
you
have
the
all
the
side-
cars
like
the
provisioner,
the
attache,
the
resizer,
the
snapshotter.
A
They
are
all
provided
by
the
kubernetes,
sig
storage
community
right
and
then
you
have
the
external
components,
which
is
the
csi
controller
driver
and
the
csi
no
driver
that
that
then
then
talks
to
a
external
storage
system.
The
storage
system
can
actually
run
on
kubernetes
itself
or
it
can
be
outside
the
cluster
entirely
right.
A
The
communication
that
is
between
the
sidecar
images
and
and
the
the
controller
driver
and
the
no
driver
is
using
a
g
or
pc
interface,
so
some
of
these
components
they
need
to
run
on
the
same
nodes,
but
the
external
storage
system
or
the
storage
system
component.
They
can
talk
over
an
entirely
different
interface
like
using
rest
and
iscsi
and
whatnot
another
detail.
You
can
see
up
there
in
the
in
the
light
bulb.
A
There
is
that
csi
drivers
today
they
may
provide
either
file
or
block
storage
and
we're
also
seeing
that
there
are
a
few
kubernetes
enhancement
proposals
around
providing
object,
storage
with
sort
of
similar
semantics.
So
we're
surely
looking
forward
to
that
and
we
all
almost
have
over
a
hundred
drivers.
There
is
90
some
drivers
available
today
right.
So,
if
you
go
to
the
the
url
that
is
on
the
slide
there,
you
will
see
a
list
of
the
different
drivers
and
also
what
kind
of
features
that
they
support.
A
And
if
you
pull
up
this
page,
you
will
then
be
able
to
see
that
there
are
certain
aspects
of
each
individual
driver
right.
So
I
I
just
took
a
good
example
here
in
the
driverless,
cfs
and
and
ceph
rdb,
which
provides
block
storage
and
they
provide
sort
of
like
different
aspects
of
the
spec
that
it
supports
and
and
different
features
right.
So
we
can
see
that
the
modes
that
the
driver
support
is
persistent,
it
doesn't
support
ephemeral,
so
the
mode
could
be
either
persistent
or
ephemeral
the
access
mode.
A
If
you
look
at
cfs,
they
can
do
read,
write
multiple
pods,
I'm
going
to
talk
about
that
later
in
this
tutorial.
What
that
actually
means,
but
this
is
just
a
way
for
you
to
kind
of
assess
the
different
drivers.
Depending
on
your
use
case,
you
can
see
that
the
block
storage
driver
will
only
support,
read,
write
a
single
pod
and
different
features
that
are
very
similar.
The
only
difference
here.
A
What
you
can
see
here
is
that
the
the
raw
block,
volume
or
the
block
volume
driver
will
support
raw
block
and
it
will
also
support,
topology
and
and
and
those
keys
are
not
needed
for
using
ceph
the
file
system
component
right
because
it's
a
distributed
file
system
will
be
available
everywhere
and
it
does
not
have
any
block
cap
capabilities
right.
So,
depending
on
your
use
case,
what
kind
of
apps
you're
deploying
you
kind
of
want
to
assess
the
driver
list
to
make
sure
that
the
driver
you're
using
supported
the
specific
capability
that
you're
looking
for.
A
All
right,
so
these
are
the
different
features
that
we're
going
to
talk
about
today
and
and
kind
of
run
through
the
different
tutorials
for
provisioning
storage
and
show
you
how
to
attach
raw
block
volumes
and
and
so
forth,
and
these
all
have
different
maturity
levels
within
kubernetes.
Today,
right
we
have
the
the
features
made.
A
Ga
and
a
few
data
features,
and
we
also
have
one
alpha
feature:
we're
going
to
talk
about
today.
The
generic
ephemeral
volumes
you
got
got
introduced
in
119,
and
it's
a
pretty
neat
addition
to.
If
you
compare
that
to
the
ephemeral,
local
volumes
and
I'm
going
to
talk
in
in
depth
about
the
difference
around
that
when
we
get
there
so-
and
this
is
also
something
you
need
to
consider
when
you
want
to
use
persistent
storage
with
your
workloads
in
kubernetes-
and
it
also
the
fact
that
different
kubernetes
distributions
they
may
mature.
A
These
features
on
on
on
a
different
cadence
or
a
faster
cadence,
depending
on
the
particular
use
cases
that
particular
vendor
want
to
cater
for.
So
that
is
also
something
to
keep
an
eye
out.
Our
ielts
on
and
all
these
different
features
are
described
in
depth
on
the
kubernetes
csi
github
repo
as
well,
and
we're
going
to
cover
most
of
these.
I'm
not
going
to
talk
that
much
about
topology.
A
I'm
going
to
touch
a
little
bit
about
that
when
we
walk
through
the
storage
class
volume
limits,
I'm
not
going
to
talk
about
that
either,
but
that's
a
way
for
the
csi
driver
vendor
to
put
a
node
limit
on
on
the
node.
How
many
volumes
you
can
provision
from
that
particular
driver
to
that
particular
node,
which
is
quite
useful
but
the
rest
of
the
capabilities.
Here,
I'm
going
to
show
volume,
expansion,
thermal
local
volumes,
volume
snapshots
and
also
use
the
persistent
volume
clone
using
the
data
source
stanza
in
the
persistent
volume
claim.
A
A
Some
of
them
have
fully
blown
operators
and
some
of
the
drivers
you
just
reference
and
a
configuration
file
that
points
to
lives
in
a
ghetto
brief
or
a
web
server,
and
that
will
install
the
driver
for
you
and
once
you
have
a
driver
or
if
you
have
access
to
a
cluster
now,
what
you
can
do
is
it's
just
you
do
a
cube.
Codel
get
csi
drivers
that
will
list
the
the
drivers
that
you
have
installed
on
your
cluster
and
the
capabilities
of
the
driver,
and
if
you
do,
a
coupe
call
get
csi
nodes.
A
You
will
see
what
nodes
in
your
cluster
have
csi
drivers
on
them
and
you
can
do
a
like
verbose
output
and
see
what
driver
they
actually
have
installed
right.
So
now
we
are
going
to
install
a
csi
driver.
That's
our
first
hands-on
lab
in
this
tutorial.
So
I'm
going
to
switch
over
to
my
terminal
and
hang
on
for
one.
Second,
all
right,
as
I
mentioned,
I'm
going
to
use
the
hpe
csi
driver
for
kubernetes,
and
you
install
that
with
helm
right
and
I'm
just
going
to
add
the
helm.
Repo
to
my
cluster.
A
I
want
to
give
the
release
a
name,
because
this
is
something
switching
from
helm2
to
helm3
obviously
provides
that
headache,
and
once
the
driver
is
installed,
you
can
do
a
cube
called
get
csi
drivers.
You
will
see
the
capabilities
of
the
driver
and
the
driver
name,
and
you
will
also
see
on
your
nodes
that
you
will
have.
I
have
four
working
nodes
in
my
cluster
and
they
all
have
the
driver
installed.
A
The
drivers
also
have
a
way
to
configure
themselves
right
so
for
the
csi
dr
hpcs
driver
for
kubernetes.
I'm.
I
need
to
provide
a
secret
that
provide
a
means
for
me
to
find
the
backend
that
I
want
to
use
right
so
for
me
to
be
able
to
start
provisioning,
storage
from
storage
classes
and
such
and
I
need
to
create
that
secret
to
make
sure
that
the
csi
provisioner
attacher
and
such
will.
They
be
able
to
find
that
secret
when
they
need
to
talk
to
the
hp
csi
driver.
A
A
For
csi
drivers.
You
need
to
have
a
list
of
keys
that
references,
the
the
secret
to
the
different
side,
cars,
and
if
you're
you
have
your
own
side,
cars,
you
need
to
call
them
out
there
as
well.
You
want
to
specify
things
like
file
system
type
and
things
like
that,
and
there
are
some
other
keys
in
the
storage
class
that
I'm
going
to
talk
about
later
in
the
presentation,
the
middle
piece
here,
the
the
user
aspect
of
it
is
that
users
create
persistent
volume,
claims
and
persistent
volume.
A
Claims
are
name-spaced
right
so
and
that
will
in
turn
he
will
request
the
access
mode.
I'm
going
to
talk
about
that
later
as
well,
what
that
is,
and
then
you
request
a
storage
size
right.
So
that
is
where
you
specify
the
capacity
in
you
can
do
either
terabyte
gigabytes
or
kilobytes
megabytes.
Whatever
uni
unit
you
want,
and
you
might
want
to
call
out
the
storage
class.
There
is
a
annotation
you
can
do
on
the
storage
class,
I'm
going
to
show
you
how
that
works
as
well.
A
A
Once
the
persistent
volume
claim
has
been
submitted
to
the
cluster,
the
dynamic
provisioner,
which
listens
to
the
that
pro
pro
specific
provisioner
name,
will
provision
something
called
a
persistent
volume,
and
that
is
a
a
stanza
that
basically
describes
the
backend
storage
right.
So
that's
where
you
will
have
your
your
driver
name
and
your
implementation,
specific
keys
and
such
and
how
to
find
the
volume
on
the
back
end.
A
So
diving
into
the
different
objects.
Here
too,
if
you
look
at
the
storage
class
here
right,
as
I
mentioned,
then
having
a
default
storage
class
is
usually
good
hygiene
right.
So
if
you
provision
a
managed
kubernetes
cluster
on
any
of
the
public
cloud
providers,
you
will
see
that
you
will
have
a
storage
class
right.
So
do
a
coupe
call
get
storage
class.
You
will
see
that
there
will
be
a
storage
class
there,
it's
mark
default
and
that
will
use
the
cloud
providers,
storage
solution
to
provide
persistent
storage
to
your
to
your
workloads.
A
In
the
case
of
csi,
you
will
have
these
keys.
That
say,
says
csi.storage.cates.io
and
a
set
of
published
secret
names
or
or
secret
namespace
for
the
different
side
course,
and
you
need
this
for
every
site
card
right,
so
the
csi
expander
sidecar
that
would
need
a
secret
and
the
publishing
and
and
a
few
others
that
you
need
to
reference
in
the
storage
class
need
to
be
pointed
out
there
explicitly.
A
You
also
have
the
ability
to
set
the
reclaim
policy
on
them
on
the
persistent
volume.
So
it's
basically
when
a
user
deletes
a
persistent
volume
claim
what
is
going
to
happen
when
that
persistent
volume
claim
gets
deleted.
Will
it
be?
Will
the
persistent
volume
that
references
to
back-end
storage
would
be
retained
on
the
cluster
or
will
it
be
deleted?
A
Another
key
here,
I'm
showcasing
is
the
volume
binding
mode
and,
if
there's
going
to
be
immediate
or
wait
for
first
consumer,
and
that
is
important
if
you're
using
a
topology
within
your
cluster
right.
So
if
you
have
a
driver
that
supports
topology,
you
might
want
to
be
able
to
separate
your
different
controllers
or
your
paws
in
different
zones
in
your
cluster
right
and
when
you
provision
storage,
you
want
to
make
sure
that
you
attach
storage
that
is
close
to
the
node
right.
A
So
what
happens
is
once
kubernetes
have
selected
a
node
to
provision
your
pod?
That's
when
the
persistent
volume
gets
provisioned
and
the
persistent
volume
will
then
be
attached
to
those
set
of
nodes
right
because
and
it
will
then
annotate
the
persistent
volume
with
the
with
the
affinity
keys,
and
that
means
that
that
persistent
volume
will
only
be
able
to
be
attached
to
those
particular
sets
of
nodes.
A
If
you
want
to
allow
the
or
if
the
csi
driver
you
want
to
use,
allows
expansion,
you
will
set
that
in
the
storage
class
as
well
right.
So
if
it
allows
expansion,
you
will
set
that
to
true
and
you
will
then
be
able
to
resize
your
persistent
volume
claims
as
you
desire
or
not
resize.
That's
the
wrong
term,
because
you
can
only
expand,
you
cannot
shrink
and
I'm
going
to
show
you
how
that
works
as
well.
A
A
The
capacity
that
I
mentioned
right
so
in
this
example,
I'm
going
to
provision
or
I'm
going
to
actually
request
a
two
terabyte
volume.
The
volume
mode
is,
is
set
to
file
system
per
default.
But
this
is
where
you
would
specify
a
volume
mode
block
if
you
want
to
provision
a
block
device
and
the
underlying
driver
supports
that-
and
you
will
also
also
be
able
to
specify
the
storage
class
name
or
or
omit
the
storage
class
name.
A
If
you
have
a
default
storage
class,
but
in
clusters,
where
you
have
multiple
tiers
of
storage,
say
you
have
a
gold,
silver,
bronze
style
thing
or
you
have
like
fast
ssd
or
slow
media
kind
of
segregation
right.
It
might
be
useful
for
users
to
be
able
to
make
that
distinction
between
provisioning,
fast
storage
or
slow
storage,
because
there's
usually
cost
associated
with
that
and
the
billing
and
accounting
apartment
is,
will
be
happier
if,
if
the
right
workload
is
running
at
the
right
place,
so
pvc
access
mode
or
persistent
volume
claim
access
mode.
A
This
is
a
graphic
I
put
together
to
kind
of
like
illustrate
what
types
of
applications
require.
Different
types
of
storage
right,
so
one
of
the
absolute
absolute
most
popular
kubernetes
controller,
to
use
with
persistent
storage
is
a
stateful
set
right
and
you
will
find
like
min
io,
rook
redis
kafka,
all
these
different
workloads
that
you
run
on
top
of
kubernetes.
A
They
use
something
called
a
state
for
staple
set
and
staple
set
in
itself.
I'm
not
going
to
cover
that
in
detail,
but
that
is
a
controller
that
has
a
has
ordered,
starts
persistent
network
naming
and
also
persistent
naming
of
the
volumes
that
gets
attached
to
each
of
the
parts
as
well
right,
and
what
happens
is
that
each
part
that
starts
up
will
basically
have
its
own
file
system.
A
So
each
part
will
benefit
greatly
by
having
a
read
write
once
persistent
volume
claim
right,
because
that
storage
will
then
be
private
to
that
pod
for
the
duration
of
that
stateful
set
right.
So
if
you
delete
the
pod,
the
port
will
attach
the
exact
same
storage
at
the
same
time
and
storage
will
also
be
provisioned
dynamically,
and
I'm
going
to
talk
about
this
in
detail
later
in
the
tutorial
as
well.
A
Another
very
popular
pattern
for
deploying
legacy
applications
on
kubernetes
is
to
use
something
called
a
deployment
right
and
in
this
case,
if
you're
using
single
replica
deployment,
they
usually
leverage
read,
write
one's
persistent
volume
claims.
So,
as
you
can
see
here,
I
have
my
sql,
both
in
the
legacy
app
single
instance
and
the
shared
nothing
distributed,
because
you
can
run
that
database
in
two
different
modes
right.
A
You
can
have
the
replicated
one
as
a
stateful
set
where
you
have
one
main
instance
and
multiple
replica
instances,
and
you
can
also
run
it
as
a
single
replica
pod,
where
you
only
have
one
single
part
accessing
one
file
system.
So
that
is
a
matter
of
preference.
How
you
would
like
to
run
that
particular
application,
and
the
same
goes
for
postgres
it
also.
Postgres
also
has
the
same
pattern
as
my
sequel
in
the
stable
set
as
well.
A
If
you
want
to
run
it
in
a
shared,
nothing
distributed
architecture
and
when
we
get
to
scalable
distributed
applications
that
require
shared
storage
right
so
say
that
you
have
nginx
a
distributed
front-end
with
a
lot
of
content
right,
it's
really
practical
to
kind
of
have
them
reference,
the
exact
same
storage
across
the
cluster.
So
when
you
scale
replicas
up
and
down
it
will
exactly.
It
will
attach
the
exact
same
storage
to
that
particular
pawn.
Also,
a
lot
of
the
ai
ml
based
workloads
like
running
a
jupiter
hub
or
kubeflow.
A
They
kind
of
see
storage
as
a
data
lake
right.
So
every
instance
that
you
spin
up
of
uber
or
you
you.
A
certain
aspect
in
your
ai
ml
pipeline-
requires
all
the
different
replicas
of
that
particular
workload
to
access
the
exact
same
storage
at
any
given
point
in
time,
and
you
accomplish
that
by
using
something
called
a
read,
write
many
persistent
volume
claims.
So
then
multiple
parts
can
access.
The
same
storage
at
any
given
time.
A
A
Only
many
storage
is
essentially
you
request
you,
you
have
to
specify
it
in
the
request
that
you
do
a
read
only
many
and
then
in
the
mount
point
you
said
I
want
to
request
this
read
only,
and
that
is
basically
how
you
request
a
read:
only
many
or
rwo
or
rwx's.
It's
called
read,
write
many,
so
I
hope
that
clarifies
the
different
aspects
of
the
persistent
volume
claim
access
modes.
A
So
with
that
said,
so
the
last
slide
kind
of
in
the
dynamic
provisioning
piece
here
is.
I
just
want
to
lay
out
the
persistent
volume
overview
here
for
our
csi
driver,
and
this
is
kind
of
slightly
abbreviated.
This
object
contains
a
lot
of
information
right,
so
so,
once
the
csi
provisioner
has
provided
instantiated
this
persistent
volume,
it
will
have
a
lot
of
metadata
around
the
driver.
What
parameters
the
driver
needs
to
attach
it
all?
The
secrets
will
be
enumerated.
A
There
will
also
be
something
called
a
claim
reference
which,
which
claim
the
pv
is
buying
bound
to
and
so
forth.
Also,
you
see
the
volume
mode
there
and
the
volume
handle
there
actually
references
the
the
back
end.
That's
basically
the
id
that
you
send
to
the
back-end
storage
to
be
able
to
see
what
to
be
able
to
look
up
the
volume
and
attach
the
volume
and
so
forth,
and
there's
also
a
bunch
of
finalizers
up
there
at
the
top
that
you'll
be
able
to
see.
A
So
that
leads
me
to
hands-on
lab
number
two
going
to
create
a
storage
class,
we're
going
to
create
a
persistent
volume
claim
and
we're
going
to
attach
a
workload
to
that
persistent
volume
claim,
and
I'm
also
going
to
show
you
how
to
expand
a
volume
for
that
running
workload.
So
hang
on,
while
I
switch
over
to
my
demo
all
right.
So
what
I'm
going
to
do
here
first,
is
I'm
going
to
show
you
the
storage
class
that
I'm
going
to
use
here.
A
I
want
to
make
this
storage
class
a
default
storage
class.
This
is
the
only
storage
class
we're
going
to
use
for
the
entire
tutorial
and
it
supports
all
the
different
capabilities
that
I
talked
about
in
the
introduction
there
and
we
need
to
specify
all
the
different
keys
for
the
site
and
we
also
want
to
specify
what
file
system
we
want
to
use.
In
this
case
xfs.
A
And
this
is
the
persistent
volume
claim
I'm
just
going
to
give
it
a
name.
Specify
access
mode
read,
write
once
because
it's
a
block,
storage
back
end,
I'm
using
and
I'm
going
to
make
that
volume
32
gig.
Initially
I'm
going
to
resize
this
later,
I'm
going
to
show
you
how
that
works.
So
we're
just
going
to
create.
A
A
Persistent
volume
all
right,
let's
see
what
we
can
do
next,
let's
yeah,
so
I'm
going
to
deploy
my
sequel
with
the
with
help,
I'm
going
to
specify
my
sql
root
password
as
admin.
I
don't
recommend
that
and
I'm
going
to
use
my
existing
claim
that
I
just
created
right.
So
I'm
just
going
to
help
install
my
sql
reference,
the
the
values
file
and
specify
stable,
slash,
mysql,
and
I
managed
to
get
the
helm
syntax
right
right
in
this
example.
A
A
A
So
it
will
do
xfs
resize
there
we
go
64
gig
now
and
once
we
kind
of
clear
this
watch
here,
we'll
jump
back
into
the
container
and
see
that
we
can
actually
leverage
that
extra
capacity
yeah.
So
there
we
go
64
gig
mounted
on
slash
wall
in
my
sequel
and
you
don't
need
to
restore
anything
or
doing
any
other
operations.
So
that
is
basically
how
simple
it
is
to
expand
a
volume
in
kubernetes
with
a
csi
driver
that
supports
it,
and
this
is
all
user
driven
right.
A
A
All
right
that
was
the
dynamic
provisioning,
101
I'd
say
I
just
want
to
talk
a
little
bit
about
the
workload
controllers
here
you
notice,
I
I
deploy
the
application
using
a
helm
chart
which
is
kind
of
practical
on
how
to
how
and
how
you
would
manage
applications
on
on
kubernetes
right.
But
what
you
see
here
in
these
two
windows
here
is
sort
of
like
most
controllers.
A
You
will
see
the
stateful
set,
and
that
is
slightly
different
from
the
other
controllers
right
there
you
have
a
construct
called
a
volume,
clamp
claim
template,
and
that
is
basically
a
it's
more
of
a
less
a
inline
specification.
A
persistent
volume
claim
specification
where
you
call
out
the
storage
class
name.
A
So
what
I'm
going
to
do
here
is
deploy
redis,
I'm
going
to
deploy
it
with
a
a
helm
chart
as
well-
and
this
is
the
values
file
I'm
going
to
provide
a
use.
Password
equals
false,
and
I'm
also
going
to
prepare
a
watch
command
here
right.
So
this
watch
command
will
watch.
My
stateful
sets
my
pods
and
my
pvc
as
redis
comes
up
right,
so
I'm
just
gonna.
Do
a
helm,
install
call
it
my
redis
reference,
my
values
file
and
I'm
going
to
use
the
bitnami
distribution
of
redis,
and
here
we
go.
A
And
here's
my
watch
command
that
I
had
prepared,
and
you
will
see
here
that
the
the
main
instance
is
already
coming
up
and
there's
also
a
a
replica
instance
being
set
up
as
well
and
down
in
the
list
of
persistent
volume
claims.
You
will
see
that
there
are
two
claims
that
has
been
fulfilled
and
now
you
can
see
that
there
is
another
pod
coming
up
and
it
automatically
created
a
new
persistent
volume
claim
right
and
once
all
these
ports
have
started
all
this.
A
That
means
that
the
the
pods
and
the
instances
that
runs
in
those
pods
will
be
able
to
find
each
other.
I'm
just
going
to
insert
a
key
here,
kubecon
status.
What
do
we
think
it's
awesome
right,
so
I'm
just
going
to
put
that
key
in
here
and
make
sure
that
we
we
flush
the
store
to
disk
and
because
I'm
gonna,
I'm
gonna,
use
this
in
in
subsequent
labs
throughout
the
presentation.
A
A
A
So
the
way
csi
snapshots
work
in
kubernetes
is
that
it
works
very
similar
to
how
persistent
storage
works
right.
So
you
have
something
called
a
volume
snapshot
class
which
allows
users
to
create
something
called
a
volume
snapshot,
and
you
will
have
the
the
csi
snapshotter
will
create
something
called
a
volume
snapshot
content
that
will
basically
point
to
the
physical
resource
that
references,
the
external
snapshot
right.
So
we
will
start
the
next
hanson
lab
by
creating
the
first
of
all
yeah.
A
I
forgot
to
mention
this
right,
so
so
the
csi
snapshot
sidecar,
is
not
installed
by
default
by
the
csi
driver.
The
csi
snapshotter
is
provided
by
the
kubernetes
distribution
right.
So
you
need
to
check
with
your
kubernetes
distribution
vendor
if
the
csi
snapshot
or
sidecar
is
installed
or
not
in
this
exercise.
A
Since
I'm
leveraging
vanilla
upstream
kubernetes,
I'm
going
to
deploy
the
external
snapshotter
as
part
of
the
hands-on
lab,
but
once
we
kind
of
pass
this,
what
you
can
do
is
when,
once
you
have
all
these
crds
installed,
you
can
create
a
volume
snapshot,
class
and
reference.
The
again,
the
csi
driver
that
you
that
you
have
installed
on
your
cluster.
Some
some
csi
drivers
provide
custom
keys
to
set
different
values
for
the
parameters
that
you
provide
to
the
volumes
natural
cloud
very
similar
to
what
you
would
do
in
a
storage
class.
A
If
you
have
any
specific
parameters,
you
want
to
supply
to
the
driver
when
you've
done
it
when
you
provision
a
snapshot
or
provision
a
volume
in
the
storage
class
case
right
and
the
volume
snapshot
is
also
very
simple.
All
you
have
to
do
is
specify
a
source
is
just
what
actual
persistent
volume
claim
do
you
want
to
take
a
snapshot
of
and,
and
that
then
will
create
a
point
in
time
copy
of
that
persistent
volume
claim
with
the
content.
A
So
with
that,
I'm
going
to
dive
into
hands-on
lab
number
four,
where
I'm
going
to
start
deploying
the
csi
snapshotter,
I'm
going
to
create
a
volume
snapshot
class
and
I'm
gonna
create
some
volume
snapshots.
So
let's
go
ahead.
I'm
gonna
switch
over
to
my
terminal
one.
Second,
all
right.
Let's
start
by
cloning,
the
kubernetes
csi
external
snapshotter
repository.
A
And
then
we
need
to
create
some
resources
that
are
provided
in
that
repository,
so
it's
the
crds
that
provides
the
volume
snatch
up
classes,
volume,
volume,
snapshot,
contents
and
volume
snapshot
that
I
just
talked
about,
and
then
you
actually
need
to
deploy
the
actual
csi
snapshot
controller
itself,
and
this
you
kind
of
need
to
do
once
per
cluster,
and
once
that's
deployed,
you
can
go
right
ahead
and
create
volume
snapshot
classes,
I'm
going
to
create
a
default
volume
snapshot
class.
I'm
only
going
to
leverage
one
in
this
particular
exercise.
A
A
All
right
we're
going
to
create
the
volume
snapshot
class
there
we
go
and
I
prepared
a
a
bunch
of
volume
snapshots
and-
and
this
will
essentially
create
new
snapshots
of
the
redis
instance
that
I
deployed
right.
So
here
are
the
the
three
parts
that
make
up
my
running
radius
instance
and
I'm
going
to
create
a
snapshot
on
each
of
those
persistent
volume
claims
that
got
created
when
I
deployed
that
radius.
A
They're,
usually
created
quite
fast
snapshots
are:
nothing
is
not
usually
a
heavy
operation
for
the
back-end
storage,
so
I
can
do
a
get
there.
We
can
see
that
they're,
I'm
immediately
ready
to
use
the
source,
pvc
that
we're
referencing
and
the
restore
size
you
can
see
in
the
column.
There
are
a
lot
of
columns
here
that
have
actually
been
truncated
and
you
can
check
the
outputs
in
the.
A
So
I'm
going
to
switch
back
to
my
powerpoint
here
in
this
first
exercise,
where
we
created
a
volume
snapshot
class
and
a
volume
snapshot.
What
I
want
to
be
able
to
do
is
to
create
a
new
persistent
volume
claim
that
references,
my
volume
snapshot.
So
this
is
an
example.
Persistent
volume
claim
how
you
would
reference
a
snapshot
when
you
create
a
pvc
right,
so
you
have
the
data
source
stanza
here,
which
calls
out
the
the
the
snapshot
name.
You
want
to
use
what
kind
it
is.
It
could
be.
A
So
you
cannot
say
that
you
took
a
snapshot
of
a
volume
and
it
was
two
terabytes.
You
actually
need
to
create
a
new
pvc
with
the
exact
sign,
it's
exact
same
size
as
the
the
volume
volume
snapshot.
So
without
further
ado,
I'm
gonna
dive
into
lab
number
five
here
or
the
hands-on
lab
number
five
and
create
a
new
pvc
from
the
volume
snapshots
that
we
just
created
and
attach
a
new
redis
instance
to
that.
A
So
I'm
going
to
use
the
the
volume
snapshots
that
we
just
created
right
and
how
I'm
going
to
attach
those
is
basically,
I
have
a
set
of
pvcs
that
references,
those
particular
snapshots
right.
So
in
my
data
source
stands
here,
I
reference
the
the
snapshots
I
want
to
use
for
each
of
the
snapshots,
I'm
basically
going
to
start
up
a
new
redis
instance
that
I
created
initially
in
this
tutorial
and
see.
If
I
have
my
key
that
I
inserted
in
the
first
exercise
right
so
now
I'm
going
to
create
those
pvcs
from
the
snapshots.
A
I
have
a
bunch
of
yaml
here
that
you
might
have
already
seen.
I
now
created
the
persistent
volume
claims
and
you
can
see
here
since
the
stateful
sets
have
predictive
naming.
I
know
what
those
the
persistent
volumes
are
going
to
be
called
right.
So
when
I
bring
up
my
redis
instance,
I
know
what
persistent
volume
claim
is
going
to
ask
for
right.
So
that's
so
when
I
name
my
new
instance,
my
new
redis.
A
A
Thankfully
helm
makes
it
easy
to
find
the
resources
that
we
want
to
look
at,
so
we
can
see
here
that
my
new
redis
instance
is
coming
up
here.
I
do
not
list
the
persistent
volume
claims
here,
because
since
I
created
a
persistent
volume,
claims
and
helm
did
not
create
that
resource.
I
wouldn't
be
able
to
qualify.
A
A
There
we
go
it's
awesome,
so
that
is
basically
how
you
would
clone
a
an
application
leveraging.
Multiple
persistent
volume
claims
from
multiple
snapshots
using
predictive
naming
thanks
to
the
the
stateful
set
right.
So
now
you
would
be
able
to
provision
as
many
instances
you
want
of
that
particular
application.
And
since
the
snapshot
pvcs
that
you
just
created
are
not
impacting
production,
you
would
be
able
to
do
destructive
changes
on
this
particular
application.
A
So
I'm
just
going
to
switch
back
to
my
powerpoint
here.
Hang
on
right.
The
next
demo,
I'm
going
to
do
is
basically
create
a
new
persistent
volume
claim
from
an
existing
existing
persistent
volume
claim,
and
that
means
that
you
won't
have
a
intermediate
snapshot
right.
So
you
will
create
the
new
pvc
directly
from
the
from
the
source.
One-
and
this
does
not
require
the
external
csi
snapshotter,
so
as
long
as
the
the
the
csi
driver
supports
data
source,
a
persistent
volume
claim
data
source.
A
A
I'm
gonna
switch
back
to
my
terminal
all
right,
so
I'm
just
gonna
show
you
the
my
pvcs
from
pvcs
and
that
this
is
very
similar
to
what
I
showed
in
the
powerpoint
slide
here,
the
data
source,
what
I'm
going
to
use
yeah
again,
I'm
going
to
use
predictive
name
naming
and
I'm
going
to
use
my
clone
redis
as
the
name.
The
data
source,
I'm
going
to
specify
is
a
persistent
volume
claim,
and
these
are
the
existing
claims
that
got
created
initially.
A
A
A
Not
running
yet
it's
not
ready.
Yet
there
we
are
there.
We
go
ready,
one
one,
all
right,
so
we
should
now
be
able
to
exec
into
my
new
clone
redis
clone
radius
instance
yep.
That's
right!
That's
the
name
and
run
this
red
cli
and
I
should
be
able
to
observe
the
key
that
we
inserted
in
the
initial
deployment
and
there
we
go.
A
And
just
to
illustrate
here,
I'm
just
going
to
list
the
volume
snapshots
and
volume
snapshot,
contents
that
we
had
and
and
this
only
references,
the
the
original
snapshots
that
we
created
right
and
what
this
basically
means
is
that
there
is
a
snapshot
created
on
the
backend
storage
system,
but
it's
a
snapshot
that
kubernetes
is
unaware
of.
So
it's
only
the
csi
driver.
A
A
Show
something
very
similar
here
so
in
this
particular
case
here.
What
is
fairly
popular,
let's
say
that
you
accidentally
delete
a
application
right,
but
you
still
have
the
volume
snapshot
say
that
you,
you
delete
the
you,
do
a
helmund
install
and
you
wipe
your
pvcs
and
all
of
a
sudden.
Oh,
that
was
not
my
intention.
A
You
just
wanted
to
install
the
app
and
reinstall
the
app,
but
you
accidentally
wiped
the
pvcs.
But
if
you
have
the
volume
snapshots,
you
will
then
be
able
to
create
a
new
a
new
instance
from
those
with
the
original
names
that
you
had
when
you
initially
deployed
the
application
and
sort
of
revert
to
your
previous
state.
If
you
so
will
right
so
say
that
you
would
have
a
that's
the
other
use
case
for
using
the
restoration
procedure
right.
So
you
would
essentially.
A
Yeah,
how
would
I
describe
this
say
that
you're
running
your
instance
in
production,
you
would
accidentally
trash
your
data
set
right,
but
you
know
that
you
have
a
snapshot
from
two
hours
before.
What
you
can
do
is
that
you
can
undeploy
or
uninstall
the
home
chart
in
this
case
and
then
remove
your
original
pvcs
and
then
create
new
pvcs
from
the
snapshots
that
you
just
created.
A
I'm
just
going
to
list
them
here
and
we
can
see
that
yeah
they're
bound
they're
good.
We
want
to
then
attach
the
redis
instance
I'm
going
to
install
the
exact
same
instance,
name
that
we
did
for
the
initial
production,
and
this
should
now
bring
back
ourselves
to
the
state.
We
were
when
we
took
the
snapshots
and
basically
be
ready
to
serve
production.
Yet
again,.
A
A
So
using
raw
block
volumes
is
quite
it's
quite
nifty.
So
you
may
have
this
in
the
persistent
volume
claims
back
in
that
stance,
that
you
have
volume
mode
block
and
you
will
also
have
the
same
ability
to
specify
particular
storage
class
or
not,
and
but
that
is
essentially
everything
you
need
to
do
to
request
a
block
volume
from
a
csi
driver
that
supports
block
storage
and
the
way
you
would
reference.
A
A
a
raw
block
volume
in
the
port
specification
is
slightly
different
from
how
you
would
do
if
it
were
a
file
system
right,
because
all
of
a
sudden
you're
dealing
with
devices
you
don't
have
file
systems
on
them
right,
so
that
that's
why
the
the
volume
mounts
stance
has
been
replaced
by
volume
devices
and
instead,
instead
of
a
mount
path.
You
have
something
called
a
device
path
and
that's
where
you
call
out
the
virtual
device-
and
it's
also
ordered
right.
A
So
the
first
device
that
comes
up
comes
to
mind
is
the
xvda
and
you
will
still
have
a
volume,
standset,
persistent
volume
claim
and
a
claim
name,
and
that
you
would
reference
and
in
in
this
particular
example,
I'm
gonna
not
yeah.
I'm
just
gonna
switch
over
to
the
hands
on
lab
number
eight
here
and
create
a
raw
block
device
and
attach
a
workload
to
that.
But
this
is
a
very
simple
example
on
how
this
works
so
bear
with
me
here
for
a
second.
A
A
And
then
I'm
going
to
run
the
very
simple
part:
it's
the
same
specification
I
had
in
the
powerpoint
actually
and
it's
just
leveraging
a
tool
called
ioping,
and
it
calls
the
claim
name
that
I
just
created,
and
here
we
have
the
the
stanza
that
calls
out
the
volume
device
and
the
device
path,
and
the
results
of
this
is
essentially
that
we
will
this
tool.
Ioping
will
will
perform,
perform
an
io
on
that
particular
device
once
per
second
per
default,
and
you
will
see
the
results
of
that.
A
A
A
It
provides
both
file
block
and
object
to
kubernetes,
and
it
uses
seth,
as
I
mentioned,
and
the
key
differentiator
here
is
that
it
allows
you
to
manage,
distributed
storage
running
on
kubernetes,
with
native
controllers
on
kubernetes,
pretty
effortless
right.
So
you
install
it
as
an
operator,
and
then
you
create
something
called
a
theft,
cluster
crd
and
it
may-
and
the
key
aspect
here
is
that
you
can
leverage
existing
pvcs
right
or
you
can
create
pvcs
like
volume
mode
with
volume
mode
block.
A
The
most
common
pattern
is
that
you
simply
leverage
a
raw
block
device
that
attached
to
the
server,
so
you
don't
have
to
use
upper
external
provisioner
at
all
right.
You
would
just
use
you
just
statically
map
in
an
nvme
device
or
whatever
you
have
attached
to
your
server,
but
if
you
want
to
deploy
multiple
clusters
and
and
kind
of
get
rid
of
the
business
of
managing
local
hardware
using
a
csi
driver
that
can
provide
a
volume,
mode
block
is
quite
practical,
actually
and
so
the
hands-on
lab
number
nine.
A
A
I
have
not
sped
up
and
this
one
I'm
going
to
have
to
speed
up,
because
it
pulls
down
a
lot
of
imager
images
for
the
operator
itself.
It
doesn't
pull
down
as
much
content,
but
once
you
create
your
set
cluster
it
take.
It
took
me
around
10
minutes
for
for
the
cluster
to
actually
get
created
and
and
come
up
so
I'm
I.
A
I
am
going
to
speed
up
this
particular
demo
when
we
get
to
that
point
right,
but
first
we
I'm
just
going
to
show
you
how
the
the
operator
gets
installed
and
then
I'm
going
to
show
you
the
ceph
cluster
stanza,
the
crd
that
instantiate
the
cluster.
So
let's
see
if
this
operator
comes
up
here
soon
enough,
so
I
have
prepared
a
sev
cluster
yaml
file
here,
and
this
is
a
vanilla,
cef
cluster.
A
I
just
copied
this
from
the
the
rook
documentation,
and
here
you
specify
something
called
a
volume
claim
template
right
and
you
set
the
volume
mode
to
block
the
access
mode.
Read
write
once
I
omit
the
storage
class
and
once
you
kind
of
create
this
cef
cluster,
it
will
dynamically
provision
storage
resources
that
it
needs
from
the
default
storage
class.
So
it
uses
actually
there's
three
volumes
being
created,
one
once
per
replica
for
the
seth
application
or
the
rookie
application.
A
Depending
on
how
you
see
it,
and
then
you
will
have
for
the
actual
data
pool
the
ceph
file
system
or
the
osds
that
is
called
in
ceph
terminology
will
provision
a
a
block.
Pvc-
and
this
is
the
point
where
I'm
going
to
pause
and
speed
up
the
presentation,
and
once
it
comes
back
we're
going
to
start
chatting
on
what
we're
seeing
so
there
it's.
Finally
up
now.
So
what
you
can
see
here,
what
got
provisioned
dynamically
is
that
you
have
a
file
system.
A
Volumes
has
been
provisioned
named,
rook
cephmon
abc,
and
then
you
have
the
data
volumes
that
basically
references
a
a
block
device
right,
and
that
is
because
the
application
components
require
a
file
system
and
the
actual
distributed
file
system.
The
cep
file
systems
require
requires
block
storage.
So
that's
why
it's
very
practical
to
have
a
driver
that
can
do
both
of
those
things
to
provide
persistent
storage
to
read,
write
one's
stateful
sets,
which
is
that
basically
presents
so
at
this
point.
A
You
basically
have
a
ceph
cluster
running
on
your
kubernetes
cluster,
so
you
would
be
able
to
install
this
f2
ball
toolbox
and
start
creating
new
storage
classes
to
provide
data
services
on
top
of
your
kubernetes,
but
it's
still
backed
by
your
backend
csi
driver
being
that
a
storage
appliance
or
it
could
be.
Your
cloud
provider's
storage
block
service.
So
now
you're
you're
more
in
the
pattern
of
kind
of
controlling
your
own
destiny,
because
you
have
your
data
services
running
on
the
kubernetes
cluster
itself,
and
that
concludes
the
the
use
case
overview
for
rook.
A
A
I
I
remember
patterns
back
in
the
darker
days,
where
we
had
the
customers,
shipping
production
databases
inside
the
container
itself.
Right
see.
Imagine
shipping,
I
mean
this
was
in
a
large
database.
It
was,
it
was
less
than
a
terabyte.
I
remember
that
much,
but
still
that
is
a
very
impractical
amount
of
content
to
to
store
in
a
in
a
container
right,
because
you
need
to
pull
that
instance
down
from
a
registry,
and
it's
just
all
that
bandwidth.
A
A
Basically,
and
this
was
for
a
dev
test
use
case.
Obviously
it
wasn't
for
production
or
anything
like
that,
but
that
became
very
impractical,
but
so
so
that
is
sort
of
where
ephemeral,
local
volumes
and
generic
ephemeral
volumes.
I'm
going
to
talk
about
in
the
next
section
is
that
that
allows
you
to
attach
a
piece
of
storage
to
your
pod.
That
will
look
exactly
the
same
each
time
right
and
by
default.
A
Of
of
that
particular
workload
is
that
it
needs
to
store
a
lot
of
data
locally
and
by
default,
if
you
would
store
the
data
inside
the
overlay
file
system
of
the
container
is
that
it
will
battle
for
iops
and
capacity
of
all
your
other
applications
on
that
particular
mount
point.
Where
you
have
all
your
containers
running
so
provisioning,
an
external
volume
as
an
ephemeral
entity,
you
will
be
able
to
temporarily
use
that
scratch
disk
for
that
compute
workload
and
it
will
consume
storage
resources
wherever
you
have
it
configured
right.
A
So
it
could
be
your
cloud
providers,
the
high
performance
tier
for
using
flash
disks,
so
you
might
be
using
a
cheaper
tier
for
your
temporary
storage
right
I
mean
the
thing:
is
you
can
kind
of
slice?
It
and
dice
it.
However,
you
want
right,
but
at
the
end
of
the
day,
is
that
you
don't
want
to
have
your
workloads
that
you
know
are
ephemeral
and
you
know
they're
io
intensive.
You
don't
want
to
have
them
in
the
gen
pop
of
your
applications
right,
you
want
to
segregate
them.
A
Some
vendors
provide
means
to
set
very
fine-grained
quality
of
service
controls
as
well
right
to
throttle
those
workloads
and
also
ensure
the
capacity
limits
are
met
right.
So
looking
at
this
very
simple
stanza
here
is
that
you
you're
well
familiar
with
this.
At
this
point
right
where
you
have
a
volume
amount,
the
amount,
the
calls
out
a
a
named
volume,
and
here
is
kind
of
where
the
the
secret
sauce
comes
in
right.
A
You,
you
have
the
csi
stanza
here
you
call
out
your
driver,
and
these
are
the
volume
attributes
that
you
you
will
supply
to
your
driver
right.
You
will
say
you
will
tell
the
driver.
I
want
an
ephemeral
volume
if
the
driver
supports
ephemerality,
and
then
you
specify
the
the
secret
where
you
can
find
it
and
which
name
space
it
is
in,
and
you
specify
a
size
right
and
some
vendors
support,
multiple
different
options
here,
how
you
want
to
provision,
storage
and
so
forth,
there's
also
a
slightly
different
way
to
reference
the
secret
right.
A
So
if
you
have
your
secret
to
your
back
in
storage
system
sitting
in
the
namespace,
with
the
application
that
you're
actually,
where
you're
deploying
the
pod
or
the
staples
at
the
home
chart,
what
not
you
can
just
reference
it
by
name
right.
So
you
give
the
the
alternative
syntax
here
by
node,
publish
secret
reference
and
name
it
csi.
A
I
have
a
very
simple
example
here
in
my
inline.yaml
I
will
have
a
mount
path
of
an
nginx
web
server,
which
is
just
a
very
simple,
stupid
container
and
very
stupid
stupid
example.
But
it
illustrates
the
point
I
want
to
make
right.
So
we
have
this,
this
inline
stanza,
where
I'm
going
to
provision
a
volume,
I'm
going
to
wait
for
the
pod
to
come
up.
A
So
I'm
going
to
go
to
slash
user
share,
nginx
html
echo
kubecon
rocks
into
index.html
there
we
go
content
is
there
and
then
I'm
going
to
do
the
the
brute
thing
of
simply
replacing
the
pod
right,
and
this
will
essentially
delete
the
pod
and
recreate
the
pod
if
we
were
referencing
a
persistent
volume
claim
externally,
the
content
would
persist
on
that
particular
amount
points.
But
the
point
I
want
to
make
here
is
that
we're
going
to
have
a
new
volume
provision
there,
so
I'm
going
to
exec
into
the
pod.
Go
to
my
mount
points.
A
A
So
I
have
a
yaml
file
here.
My
ephemeral
yaml
and
here
you
can
see
that
I
have
a
ephemeral
volume
claim
template.
I
input
some
metadata
there,
so
I
will
be
able
to
find
the
application
and
you
can
see
here
the
access
mode,
how
much
storage
I'm
requesting
and
the
the
custom
label
I'm
going
to
create
that
and
then
I'm
going
to
do
the
exact
same
exercise
I
did
in.
In
the
previous
example
with
the
inline
local
volume
example,
I'm
going
to
wait
for
the
part
to
come
up.
A
A
There's
no
file
there,
the
generic
ephemeral
volumes
functionality
worked
as
advertised,
although
is
a
alpha
feature,
be
careful,
and
you
will
also
see
that
the
the
pvc
has
been
replaced
from
my
default
storage
class
there,
as
you
can
see
that
the
if
you
compare
the
ids
of
the
the
volume
names
there
they're
different
all
right.
That
concludes
hands-on.
Lab
number
11.,
I'm
going
to
switch
by
back
to
my
powerpoints
and
congratulations
you're
done.
A
As
I
mentioned,
the
source
files,
the
yaml,
the
powerpoint,
the
asciinima
cast
files
are
all
available
in
this
particular
github
repository
check
out
the
csi
specification
and-
and
you
can
also
see
all
the
past
meetings
and
and
the
members
of
the
kubernetes
special
interest
group
for
storage
on
the
github
url
there
and
check
out
the
csi
documentation
for
more
information
about
the
development
of
csi
and
the
different
maturity
levels
of
different
drivers
and
and
features,
and-
and
god
knows
one
so
with
that
said.
Thank
you
so
much
for
watching.
A
If
you're
watching
this
live
at
kubecon,
please
stick
around
we're.
Gonna
shut
down
this
video
stream
and
we're
going
to
switch
over
to
the
live
q
a
and
until,
if
you're,
watching
this
offline
later,
please
feel
free
to
reach
out
to
me.
If
you
have
any
questions,
you
can
find
me
on
twitter
and
all
this
social
media
networks
out
there.
The
address
is
in
the
beginning
of
the
video,
so
thank
you
so
much
for
watching
take
care.