►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Kubernetes SIG-Storage Intro and Update - Xing Yang, VMware & Jan Šafránek, Red Hat
Kubernetes SIG Storage is responsible for ensuring that different types of file and block storage are available wherever a container is scheduled, storage capacity management (container ephemeral storage usage, volume resizing, etc.), influencing scheduling of containers based on storage (data gravity, availability, etc.), and generic operations on storage (snapshotting, etc.). In this session, we will give an introduction to SIG Storage and then deep dive into some projects that SIG Storage is currently working on, provide an update on the current status, and discuss what might be coming in the future.
A
B
A
A
A
Seek
storage
is
responsible
for
the
life
cycle
of
volumes
used
by
pots.
This
includes
provisioning,
a
new
volume
attaching
a
volume
to
the
node
and
mounting
it,
so
that
part
can
use
it
I'll,
mounting
detaching
and
deleting
the
volume
when
it
is
no
longer
needed
taking
snapshots
so
that
it
can
be
used
to
restore
the
volume.
A
A
We
have
the
suit
class
concept.
A
student
class
provides
a
way
for
administrators
to
describe
the
classes
of
storage.
They
offer
different
classes,
might
map
to
different
quality
of
service
levels
in
dynamic
provisioning
student
class
is
used
to
find
out
which
provisioner
should
be
used
and
what
parameters
should
be
passed
to
the
provisioner
when
creating
the
volume
sig
storage
has
been
working
on
migrating
from
entry
point
plugins
to
auto
3
csi
drivers.
A
A
A
Release
in
1.20
csi
snapshot
feature
mode
to
ga.
A
snapshot
represents
a
point
in
time
copy
of
the
volume
it
can
be
used
as
a
data
source
to
create
a
new
volume.
This
feature
provides
a
basic
building
block
for
supporting
data
protection
in
kubernetes,
backup
vendors
are
standardizing
on
css
snapshot
apis
to
build
their
backup
solutions.
A
A
A
Traditionally,
if
your
pod
is
running
as
a
male
user,
you
must
specify
an
fs
group
inside
the
pods
security
context,
so
that
the
volume
can
be
readable
and
rivaled
by
the
pod.
However,
there
is
a
downside.
Each
time
a
voting
is
mounted
kubernetes
must
recursively
change
or
change
mode,
all
the
files
and
directories
inside
the
volume.
A
A
The
second
one
is
the
csr
driver
policy
for
fs
group.
The
cc
driver
now
has
a
fs
group
field
which
allows
for
the
drivers
to
explicitly
opt
in
or
out
of
recursive
modifications.
This
way
kubernetes
can
avoid.
Needless
modification
attempts.
Thus
optimization
helps
to
reduce
volume.
On
time
there
is
a
default
policy
called
read,
write
once
with
the
fs
type
it
is
applied
if
a
no
fs
group
policy
is
defined.
A
This
preserves
the
behavior
from
previous
kubernetes
releases
in
window
20.
We
also
added
a
new
feature
called
a
pass
part
series
account
token
to
csi.
This
provides
a
way
to
obtain
service
account
token
for
parts
that
the
csr
drivers
are
mounting
volumes
for,
since
these
tokens
are
valid
only
for
a
limited
period.
This
feature
also
gives
the
csr
drivers
an
option
to
re-execute
node
publish
volume
to
mount
volumes,
so
this
is
what
we
did
in
1.20
next,
I
will
talk
about
what
we
did
in
1.21
release.
A
In
1.21
release,
we
have
this
immutable
secrets
and
config
maps
moved
to
ga.
This
feature
allows
users
to
specify
the
contents
of
a
particular
secret
or
config
map
that
should
be
immutable
for
the
lifetime
of
the
object
for
such
secrets
and
complete
map.
Cubelets
will
not
watch
o
for
changes
to
updated
amounts
for
their
parts,
so
that
will
reduce
the
load
on
the
api
server.
It
also
enables
users
to
better
protect
themselves
against
ex
accidental
bad
updates
that
could
cause
outages
in
1.21.
A
A
We
also
have
a
few
feature
that
moved
to
beta
in
minor
21,
so
we
have
a
storage
capacity
tracking
that
becomes
a
beta
feature.
Traditionally,
the
kubernetes
scheduler
was
based
on
the
assumption
that
additional
persistent
volume,
additional
position
storage
is
available
everywhere
in
the
cluster
and
has
infinite
capacity.
A
A
3d
capacity
tracking
addresses
that,
by
adding
an
api
for
a
csr
driver
to
report
3d
capacity
and
uses
that
information
in
the
kubernetes
scheduler
when
choosing
a
node
for
a
pod-
and
we
also
have
a
generic
aphmar
volumes,
feature
moved
to
beta
kubernetes
provides
rolling
plugins
because
the
lifecycle
is
tied
to
a
pod
and
can
be
used
as
a
scratch.
Space
such
as
the
built-in
empty
data
volume
type
or
to
load
some
data
to
a
pod,
such
as
the
view
in
configmap
and
secret
volume
types
or
csi
inline
volumes.
A
The
generic
asmr
volumes
feature
allows
any
existing
storage
driver
that
supports
dynamic
provisioning
to
be
used
as
an
admiral
volume.
With
the
volume's
lifecycle
back
to
the
pod,
it
can
be
used
to
provide
scratch
storage
that
is
different
from
the
root
disk.
For
example,
persistent
memory
or
a
separate
logo
disk
on
that
node
all
surge
class
parameters
for
warning
provisioning
are
supported.
A
A
A
A
A
B
B
B
B
Another
feature
we
are
valuating
for
some
time
is
volume
expansion.
It
is
in
beta.
It
is
in
beta
for
a
long
time
and
it
works
pretty
well.
However,
there
are
still
some
nasty
corner
cases
we
need
to.
I
I
run
out
and
then
we
have
number
of
features
in
design
and
prototyping
phase
again,
only
only
the
most
interesting
ones
here
below
recovery
from
volume,
expansion
failures
is
one
huge
corner
case
of
volume
expansion.
B
But
if
a
user,
for
example,
asks
for
two
big
volumes
like
exabytes,
the
storage
backend
is
probably
going
to
reject
the
expansion
and,
again
and
again
as
kubernetes
tries
to
resize,
then
the
storage
end
it'll
will
reject
it
and
at
the
same
time
we
don't
allow
users
to
shrink
volumes.
So
this
user
is
basically
stuck
because
they
will
not
get
those
exabytes
they
asked
for,
but
they
cannot
cancel
the
operation
at
the
same
time.
B
Another
feature
is
volume
groups,
and
we
want
to
allow
users
to
put
their
persistent
volume
claims
into
higher
level
groups,
and
this
will
allow
interesting
features
like
taking
snapshot
of
a
whole
group
as
as
a
whole.
At
the
same
time,
because
with
snapshots
we
have
today,
you
can
take
snapshots
of
a
single
pvc
and
if
you
want
to
take
snapshot
of
more
of
them,
then
you
need
to
do
it
one
by
one
and
they
will
be
taken
at
a
different
time.
Basically,
so
with
worm
groups,
you
could
take
the
snapshot
of
a
whole
group.
B
Generic
data
generic
volume
populators
expands
on
an
idea
we
introduced
with
volume,
cloning
and
restoring
snapshots.
In
the
early
days
of
kubernetes,
a
newly
dynamically
provisioned
volumes
were
always
empty,
and
today,
with
cloning
and
snapshots,
you
can
pre-populate
a
volume
with
either
content
of
a
different
volume.
That's
the
cloning
or
with
a
restored
snapshot
and
data
populators.
B
With
data
populators,
anybody
could
write
a
piece
of
code
that
can
pre-populate
a
volume
during
dynamic
provisioning,
with
virtually
anything.
For
example,
it
the
populator,
could
clone
a
git
repository
or
put
their
content
of
container
image
or
a
virtual
machine
image,
or
basically,
whatever
we
had
volume
populators
in
kubernetes,
since
kubernetes
118
and
in
122.
The
api
should
be
complete
and
in
beta.
B
B
B
Here
we
are
expanding
on
volume
snapshots
again
and
right
now,
right
now,
if
you
take
a
snapshot
of
a
single
volume
and
the
application
it
can
be
still
running,
so
there
can
be
a
pot
of
writing
to
the
volume.
At
the
same
time,
we
take
the
snapshot
like
most
applications,
like
databases
can
recover
from
partly
written
data.
If
you
restore
the
snapshot,
then
you
can
see
only
part
of
the
data
written,
so
the
databases
can
usually
recover
from
that,
but
it's
not
ideal.
B
When
taking
a
snapshot,
we
could
poke
the
pot
to
flush
the
caches
and
transactions
and
everything
and
possibly
phrase
the
file
system.
Then
you
can
take
the
snapshot
and
then
resume
the
application,
so
the
snapshot
will
be
consistent
from
the
application
point
of
view,
and
when
this
is
combined
with
the
volume
groups
I
called
before
you
could
take
a
snapshot
of
a
whole
stateful
set
and
the
snapshot
could
be
granted
to
be
consistent.
B
So
this
was
the
application
side
of
backups,
while
change
block
tracking
helps
with
the
back-end
side.
So
we
a
backup
software,
could
do
a
diff
between
two
snapshots
and
get
the
list
of
change
blocks
between
these
two
snapshots.
So
it
could
take
a
backup
only
of
those
backup
only
of
those
changed
blocks
to
speed
up
the
backup
and
to
save
some
storage
capacity
and
also
transfer
bandwidth
together
with
sig
apps.
B
Currently,
when
a
node
becomes
unavailable
from
whatever
reason,
kubernetes
will
not
detach
volumes
from
that
node,
because
the
node
can
be
still
running
just
it
may
not
be
able
to
talk
to
the
api
server
so
detaching.
Such
volumes
would
corrupt
the
volumes
because
they
are
still
mounted
on
the
node.
B
But
what?
If
we
know
that
the
node
is
shut
down,
if
the
node
is
shut
down,
then
the
volumes
are
not
mounted.
We
are
pretty
sure
and
we
can
detach
the
volumes
and
we
can
attach
them
somewhere
else,
so
the
ports
that
use
the
volume
can
be
rescheduled
to
the
other
nodes
and
your
application
can
resume
much
quicker
than
today.
B
B
B
B
B
B
B
We
just
follow
the
generic
kubernetes
one,
so
you
will
need
to
create
a
tracking
issue,
so
others
other
people
can
know
that
there
is
a
feature
in
progress
being
developed
and
you
will
need
to
write
the
kubernetes
enhancement
proposal
cap
in
short
and
shepherd
it
through
various
reviews
and
through
alpha
beta
and
ga
phases,
don't
be
afraid
and
again
yeah.
We
are
here
to
help
you
with
those
processes.
B
We
are
always
interested
in
new
contributors.
Every
little
pull
request
counts.
It
doesn't
need
to
be
a
whole
new
feature.
You
can
improve
our
documentation
at
unit
tests
at
e2e
tests
or
do
some
minor
refactoring.
If
you
see
the
the
code
is
ugly,
it's
up
to
you
and
your
contribution
will
be
always
welcome.